Re: chroot(2) and bind mounts as non-root

[Colin Walters <walters@verbum.org>]

On Mon, 2011-12-12 at 23:11 +0000, Serge E. Hallyn wrote:

> Look at the cap_get_bound.3 manpage, and look for CAP_IS_SUPPORTED.
> If you start at CAP_LAST_CAP and keep going up/down depending on whether
> it was support or not it shouldn't take too long to find the last
> valid value.  Not ideal, but should be reliable.

Blah =/  I think I'll just rely on the MS_NOSUID bind mount for now.

> I haven't taken a critical look at the mount code but other than that
> it seems reasonable and useful to me!  Thanks.

Can you link me to any discussion of how the user namespace stuff you're
working on would enable any of this (chroot, bind mounts) to be
available to "unprivileged" users?  Is it that once a non-uid 0 process
enters a new namespace, when executing a setuid 0 binary from the
filesystem, because that binary is from a different user namespace, the
setuid bits don't apply?

What does it even mean for a file to be "owned" by a user namespace -
unless you're talking about patching e.g. ext4 to persist namespaces
somehow.

Where I'd ultimately like to get is having this utility in util-linux,
but before I propose that I'd like to have a good idea what the
possibilities are with user namespaces.

The more I think about this though, the more I am a big fan of what the
OpenWall people are doing - if it gets me chroot as a user, I am totally
on board with just removing all setuid binaries.  We're already fairly
far along on doing that in GNOME by using PolicyKit mechanisms anyways.