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

Jan Hudec
2005-05-13T07:21:05Z

[-- 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 --]