> > > I'm asking you to expand on what the problems would be if we were to
> > > enhance the namespace code as suggested.
> >
> > OK, what I was thinking, is that the user could create a new
> > namespace, that has all the filesystems remounted 'nosuid'. This
> > wouldn't need any new kernel infrastructure, just a suid-root program
> > (e.g. newns_nosuid), that would do a clone(CLONE_NEWNS), then
> > recursively remount everything 'nosuid' in the new namespace. Then
> > restore the user's privileges, and exec a shell.
> >
>
> I'm confused why everything has to be remounted nosuid. I understand
> enforcing synthetics to be mounted nosuid, but not the rest of the
> file systems.
It's related to the problem of a suid program accessing synthetic
filesystem, and filesystem doing something bad to suid program (make
it hang, supply bogus data ...). This can be solved by "squashing"
suid for the whole namespace (basically the Plan 9 solution).
Unfortunately this is not really practical in Linux/Unix.
> I thought all the problems revolving around the private namespace
> solution where the FUSE team's desire to have per-user namespace
> and/or per-session namespace versus per-process namespace.
That's a different aspect of this thing. Private namespaces cannot do
anything about the above problem.
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]
