apache / apache/buildstream

setcap in sandbox: Operation not permitted

Open
#1,375 5 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.