Serge Hallyn <serge.hallyn@xxxxxxxxxx> writes: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> What I meant is that it isn't about containers. It is about something >> root can do. So this is not a "container" problem. > > Oh, ok. > > Sorry, I'm getting the two thread confused anyway. I'm going to bow out > here until I can pay proper attention. I think there is half a point here that may be legit, when you are using mount namespaces to jail applications, there may be a problem with umounting / and making it to the underlying rootfs filesystem. I am squinting and looking this way and that but while I can imagine someone more clever than I can think up some unique property of rootfs that makes it a little more exploitable than just mounting a ramfs, but since you have to be root to exploit those properties I think the game is pretty much lost. >> >> 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. > > ? you can always escape if you're simply chrooted. waterbuffalo :) filesystem type rootfs. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
