> >
> > ... is the same as for the same question with "set of mounts" replaced
> > with "environment variables".
>
> Not quite.
>
> After changing environment variables in .profile, you can copy them to
> other shells using ". ~/.profile".
>
> There is no analogous mechanism to copy namespaces.
>
> I agree with you that Miklos' patch is not the right way to do it.
I'm not sure that it is either. But, see bellow...
> Much better is the proposal to make namespaces first-class objects,
> that can be switched to. Then users can choose to have themselves a
> namespace containing their private mounts, if they want it, with
> login/libpam or even a program run from .profile switching into it.
It would be good if it could be done just in libpam. But that would
require every libpam user to call into it after the fork() or
whatever, so unshare() and join_namespace() don't mess up the server
running environment.
If not, then it would mean modifying numerous programs, having these
modifications integrated, then having distributions pick up the
changes, etc. I would imagine quite a long cycle for this to be
acutally useful.
> While users can be allowed to create their own namespaces which affect
> the path traversal of their _own_ directories, it's important that the
> existence of such namespaces cannot affect path traversal of other
> directories such as /etc, or /autofs/whatever - and that creation of
> namespaces by a user cannot prevent the unmounting of a non-user
> filesystem either.
>
> The way to do that is shared subtrees, or something along those lines.
Yes, but we would be achieving essentially the same as my patch, just
with more complexity. And my patch achieves what FUSE does in 2 lines
of code, namely hide the mount from other users by returning -EACCESS
in case fsuid does not mach the mount owner.
I aggree that your solution is more flexible, but it's also hugely
more complex. If somebody want's to implement it, fine. But don't
expect me to do it, unless some company hires my for fs development
(hint, hint ;)
Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
