On Thu, 2005-05-19 at 08:04 +0200, Enrico Scholz wrote: > It will cause lot of problems when two regular sessions have a different > view of the filesystem. E.g. when session A mounts /media/cdrom, this > will not be available in session B. Work is going on on making "shared subtrees" as I think they're called working upstream. > Or the /etc/mtab designflaw of 'mount'... it is not NS aware, and although > it causes other problems e.g. in read-only / it was impossible to eradicate > it in all the years. Yeah...that's a can of worms. > Think of automounting /home/foo: In root-namespace (where the automounter > was started), nobody accessed this dir and is is not mounted yet. I think this is essentially the same issue as the first one; if we have shared subtrees then this should work. > > noexec's always been virtually useless. > > Why? The '/lib/ld-2... /tmp/foo' trick does not work anymore with recent > kernels. That's cool that that hole is closed, although I wonder if there are other ones. Besides that, there's a few other facets of "useless": first, that lots of things break on noexec /tmp, and second, you need to ensure that there aren't any other writable areas that aren't mounted noexec, and third, SELinux gives you a much more fine-grained control over execute permissions anyways. > >> * CLONE_NEWNS + 'mount --bind' are not very well documented and it is > >> often unclear whether strange behavior is expected or not. E.g. it may > >> happen that '/' and '/..' are pointing to different inodes; dunno if > >> this is wanted or not. > > > > Hm, so it might confuse tools? > > Yes, it breaks e.g. chroot operations of yum. Even just for a new /tmp namespace? Seems surprising. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
