Re: [RCF] [PATCH] unprivileged mount/umount

[Miklos Szeredi <miklos@szeredi.hu>]

> > So if a user creates a private namespace, it should have the choice of:
> > 
> >    1) Giving up all suid rights (i.e. all mounts are cloned and
> >       propagated with nosuid)
> > 
> >    2) Not giving up suid for cloned and propagated mounts, but having
> >       extra limitations (suid/sgid programs cannot access unprivileged
> >       "synthetic" mounts)
> 
> (2) isn't realistic.  There's no such thing as a suid program.  Suid is a 
> characteristic of a _file_.  There's no way to know whether a given 
> executing program is running with privileges that came from a suid file 
> getting exec'ed.  Bear in mind that that exec could be pretty remote -- 
> done by a now-dead ancestor with three more execs in between.
> 
> Many user space programs contain hacks to try to discern this information, 
> and they often cause me headaches and I have to fix them.  The usual hacks 
> are euid==uid, euid==suid, and/or euid==0.  It would be an order of 
> magnitude worse for the kernel to contain such a hack.

Guess what?  It's already there.  Look in ptrace_attach() in
kernel/ptrace.c

You could argue about the usefulness of ptrace.  The point is, that
suid/sgid programs _can_ be discerned, and ptrace _needs_ to discern
them.

And for the same reason, user controlled filesystems also need to do
this check.  See Documentation/filesystems/fuse.txt in -mm and later
discussion in this thread for more information.

The strange thing is that people argue so vehemently about this on
theoretical grounds.  But practice shows, that there's in fact no
problem with it whatsoever.  This check (or something similar), has
been in FUSE for more than 3 years, used by thousands of people, and
it didn't cause _any_ problems, except various sub-mount related
things, which we are trying to solve properly, by making mount
unprivileged.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/