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

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

On Fri, May 13, 2005 at 07:47:07 +0200, Miklos Szeredi wrote:
> > >    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.

I actually neither needs to, nor does. For ptrace the definition is:
    If the tracee has different privilegies, than the tracer, than it
    can't be traced.

For this definition, the check is not a hack. It's the only way to go.

Now this definition is really what is needed for the filesystem case
too, so I think it's not a hack either. 

> 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.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]