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.