Serge Hallyn <serge.hallyn@xxxxxxxxxx> writes: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: >> >> 2> On Tue, Oct 07, 2014 at 02:30:40PM +0100, Al Viro wrote: >> >> On Tue, Oct 07, 2014 at 04:12:57PM +0400, Andrey Vagin wrote: >> >> > Another problem is that rootfs can't be hidden from a container, because >> >> > rootfs can't be moved or umounted. >> >> >> >> ... which is a bug in mntns_install(), AFAICS. >> > >> > Ability to get to exposed rootfs, that is. >> >> The container side of this argument is pretty bogus. It only applies >> if user namespaces are not used for the container. > > User namespaces are still far too restricted for many container use > cases. We can't say "we have user namespaces so now privileged > containers can be ignored". Yes you never should have handed the > keys to a privileged container to an untrusted person, but we do > still try to protect the host from accidental damage due to a > privileged container. What I meant is that it isn't about containers. It is about something root can do. So this is not a "container" problem. >> So it is only root (and not root in a container) who can get to the >> exposed rootfs. >> >> I have a vague memory someone actually had a real use in miminal systems >> for being able to get back to the rootfs and being able to use rootfs as >> the rootfs. There was even a patch at that time that Andrew Morton was >> carrying for a time to allow unmounting root and get at rootfs, and to >> prevent the oops on rootfs unmount in some way. >> >> So not only do I not think it is a bug to get back too rootfs, I think >> it is a feature that some people have expressed at least half-way sane >> uses for. > > They can still do that if they want, using chroot :) It would take fchdir or fchroot and a directory file descriptor open on rootfs. Frequently there is no appropriate directory file descriptor. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
