Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[merged] Don't call capset() unless we need to #122

Closed
wants to merge 1 commit into from

Conversation

cgwalters
Copy link
Collaborator

Fedora runs rpm-ostree (which uses bwrap) in systemd-nspawn (in mock via
--new-chroot). nspawn by default installs a seccomp policy that
denies capset().

This started failing with bubblewrap-0.1.4:
https://pagure.io/releng/issue/6550

The process currently runs as real uid 0, outside of a user namespace.
(It's honestly a bit nonsensical for nspawn to give a process CAP_SYS_ADMIN
outside of a userns, but use seccomp to deny capset(), but let's leave
that aside for now.)

Due to the way this code was structured, we set is_privileged = TRUE
simply because we have uid 0, even in the Fedora case where we aren't
privileged.

Fix this so we only set is_privileged if uid != euid, hence we
won't try to gain/drop any capabilities, which fixes compatibility
with what nspawn is doing.

In theory of course we could drop privileges in a userns scenario,
but we'd only be dropping privs in our userns...eh.

Fedora runs rpm-ostree (which uses bwrap) in systemd-nspawn (in mock via
`--new-chroot`).  nspawn by default installs a seccomp policy that
denies `capset()`.

This started failing with bubblewrap-0.1.4:
https://pagure.io/releng/issue/6550

The process currently runs as *real* uid 0, outside of a user namespace.
(It's honestly a bit nonsensical for nspawn to give a process `CAP_SYS_ADMIN`
 outside of a userns, but use seccomp to deny `capset()`, but let's leave
 that aside for now.)

Due to the way this code was structured, we set `is_privileged = TRUE`
simply because we have uid 0, even in the Fedora case where we *aren't*
privileged.

Fix this so we only set is_privileged if `uid != euid`, hence we
won't try to gain/drop any capabilities, which fixes compatibility
with what nspawn is doing.

In theory of course we *could* drop privileges in a userns scenario,
but we'd only be dropping privs in our userns...eh.
@alexlarsson
Copy link
Collaborator

@rh-atomic-bot r+ 0b66e9f

@rh-atomic-bot
Copy link

⌛ Testing commit 0b66e9f with merge 4a92ad1...

@rh-atomic-bot
Copy link

☀️ Test successful - status-redhatci
Approved by: alexlarsson
Pushing 4a92ad1 to master...

@rh-atomic-bot rh-atomic-bot changed the title Don't call capset() unless we need to [merged] Don't call capset() unless we need to Dec 1, 2016
cgwalters added a commit to cgwalters/bubblewrap that referenced this pull request Dec 5, 2016
containers#122 introduced a
regression for the case of rpm-ostree running bubblewrap on CentOS 7.

Previously the `is_privileged` variable captured whether or not
our uid was 0, now it captures whether we're setuid.

This bit of code enabled `--unshare-user` automatically if we're not
privileged, but we suddenly started doing that for running as real uid
0 (CAP_SYS_ADMIN), which we don't want, since on CentOS/RHEL 7 today
userns isn't even available to root without a module parameter and
reboot.

So, let's just do this only if not setuid *and* we're not uid 0
(really we should check "have CAP_SYS_ADMIN" but eh).
rh-atomic-bot pushed a commit that referenced this pull request Dec 5, 2016
#122 introduced a
regression for the case of rpm-ostree running bubblewrap on CentOS 7.

Previously the `is_privileged` variable captured whether or not
our uid was 0, now it captures whether we're setuid.

This bit of code enabled `--unshare-user` automatically if we're not
privileged, but we suddenly started doing that for running as real uid
0 (CAP_SYS_ADMIN), which we don't want, since on CentOS/RHEL 7 today
userns isn't even available to root without a module parameter and
reboot.

So, let's just do this only if not setuid *and* we're not uid 0
(really we should check "have CAP_SYS_ADMIN" but eh).

Closes: #123
Approved by: alexlarsson
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants