Re: -mm -> 2.6.13 merge status (fuse)

[Miklos Szeredi]

> > > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/