setcap in sandbox: Operation not permitted
- Dominant language
- Python
- Stars
- 140
- Forks
- 45
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 6
Description
[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/1375)
In GitLab by [[Gitlab user @valentindavid]](https://gitlab.com/valentindavid) on Jul 29, 2020, 09:32
## Summary
[//]: # (Summarize the bug encountered concisely)
`setcap` does not run in the sanbox. It always returns "Operation not permitted". But this is need when building
bootable images.
For example, shadow's `newuidmap` needs `cap_setuid+ep`.
## Steps to reproduce
[//]: # (How one can reproduce the issue - this is very important)
Use those commands in the sanbox:
```
- touch foo
- setcap cap_setuid+ep foo
```
## What is the current bug behavior?
[//]: # (What actually happens)
"Operation not permitted"
## What is the expected correct behavior?
[//]: # (What you should see instead)
Works.
## Relevant logs and/or screenshots
[//]: # (Paste any relevant logs - please use code blocks ``` to format console output, logs, and code as it's hard to read otherwise. You can also add a Snippet and link it here. Check the markdown giude on Gitlab for further tips)
## Possible fixes
[//]: # (If you can, link to the line of code that might be responsible for the problem)
The sandbox could "fakeroot" attribute `security.capability` through fuse.
## Other relevant information
Note that though it is related to #38, it is a separate issue. #38 is about storing the attributes in the artifact. This issue is about allowing setcap within the sandbox. We can always work around #38 by packing the filesystem (tar, ostree, etc.). But we cannot get setcaps without fixing this issue.
Also, the capabilities do not have to be stored on the actual filesystem, and the capabilities do not have to work. The only important thing is that we can read the capabilities back.
[//]: # (Add the BuildStream version. Substitute below the "x" by "1", "2" or the right version. Add more than one version if necessary)
* BuildStream version affected: /milestone %BuildStream_v1.x
----
Contributor guide
Research direction
Start by reproducing the issue inside the sandbox with `touch foo` and `setcap cap_setuid+ep foo`, then inspect the sandbox implementation and its existing capability handling. Done means `setcap` no longer returns “Operation not permitted” and the capability can be read back, without requiring it to work on the actual filesystem.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- build-system, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100