1
# rpm -q --whatprovides /usr/bin/unshare
util-linux-2.32-2.fc28.x86_64
# unshare -r
#

i.e. the above succeeds, where the following does not. What rule causes this?

# rpm -q --whatprovides /usr/sbin/chroot
coreutils-8.29-6.fc28.x86_64
# chroot fedora-27
# rpm -q --whatprovides /usr/bin/unshare
util-linux-2.30.2-1.fc27.x86_64
# strace unshare -r
...
unshare(CLONE_NEWUSER)      = -1 EPERM (Operation not permitted)
1

https://serverfault.com/a/648637/133475

It's well-known that processes that are capable of using chroot, are capable of breaking out of a chroot. Since unshare -r would grant chroot permissions to an ordinary user, it would be a security risk if that was allowed inside a chroot environment. Indeed, it is not allowed, and fails with:

unshare: unshare failed: Operation not permitted

which matches the unshare(2) documentation:

EPERM (since Linux 3.9)

CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller's root directory does not match the root directory of the mount namespace in which it resides).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.