On Mon, Mar 2, 2015 at 1:47 PM, Eric W. Biederman <[email protected]> wrote: > Andy Lutomirski <[email protected]> writes: > >> On Mon, Mar 2, 2015 at 9:09 AM, Eric W. Biederman <[email protected]> >> wrote: >>> MS_REC should be only required if there is something mounted on top of >>> one of the files in sysfs. It sounds like there is, and exposing that >>> file would be a permission issue. >>> >> >> What's mounted on /sys? >> >> If it's just /sys/fs stuff, then I'd argue that we should exempt it >> and allow the non-recursive bind mount. > > I disagree. Having looked at the code to remind myself excactly what we > are dealing with the only case that will require MS_REC on a bind mount > are locked mounts. We have locked mounts because it was the real root > user who mounted something on top of sysfs. > > All of the mounts get locked together after: > > unshare(CLONE_NEWUSER|CLONE_NEWNS); > > We don't have a reliable test that could say some mounts never need to > be locked together. So Andy I disagree that we should exempt anything, > it is not technically feasible at this point. > > If we can figure out how to get a dentry bit that says and enforces a > directory will always be empty and we should never lock mounts on top of > it. It might be worth reconsidering things. But right now I have no > interest in relaxing something that works and is not particularly complicated.
It's a matter of how much a problem recursive mounts are for /sys/fs. The contents on my machine are: $ ls /sys/fs cgroup ext4 fuse pstore selinux xfs We could alternatively add a *mount* bit that tells the kernel that this mount shouldn't lock the underlying mount. OTOH, arguably the right solution is to get userns FUSE support merged and use it for absurd things like sysfs mounts in unprivileged containers. --Andy > > > Eric -- Andy Lutomirski AMA Capital Management, LLC _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
