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

[Bryan Henderson]

>For ptrace the definition is:
>     If the tracee has different privileges, 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.

I agree this is the proper goal for ptrace and this code is not a hack. 
It's a bug.  In Linux, uid, euid, suid, gid, egid, and sgid do not by 
themselves determine privileges.  And that's what ptrace checks.  The main 
determiner of basic privileges is the process capabilities.  The euid, 
etc. do also.   I have frequently have on my system a process that runs 
with the same uid, euid, etc. as some other process, but should not be 
allowed to ptrace it because the tracee has CAP_DAC_OVERRIDE (the 
privilege to access files in spite of file permissions) and the tracer 
does not.  (Furthermore, the tracee got that privilege courtesy of a 
set-uid file, but as we seem to agree, that is not relevant here).

So as with the user space programs I mentioned (where the euid check is 
indeed a hack), I have to fix ptrace too.  Fortunately, it looks as simple 
as comparing capability sets.

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

Maybe I got lost in the problem we were trying to solve, then.  What does 
comparing the privileges of one process with those of another have to do 
with this thread about making safe unprivileged mounts via namespaces? The 
post to which I replied said we have to deal with set-uid programs. Aren't 
we talking about the problem where someone sets a file's setuid flag on 
with the assumption that when the program within runs, it will see certain 
files at certain places?  And the fact that if one could mount whatever he 
wants, that would violate the assumption?  The two ways suggested of 
handling that are: 1) after the private mount, ignore all setuid flags. 2) 
after the private mount, don't let a program that has gained privileges 
via set-uid see the user-made names.

My point is still that (2) can't be done because you can't know that a 
program has gained privileged via set-uid.

If it's really not about set-uid, but about ptrace-like privilege 
borrowing, please enlighten me.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

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