Re: [1/1][PATCH] nproc v2: netlink access to /proc information

[Roger Luethi <rl@hellgate.ch>]

On Tue, 14 Sep 2004 09:37:12 -0700, William Lee Irwin III wrote:
> On Tue, 14 Sep 2004 08:37:58 -0700, William Lee Irwin III wrote:
> >> No, in general races of the form "permissions were altered after I
> >> checked them" can happen.
> 
> On Tue, Sep 14, 2004 at 06:01:50PM +0200, Roger Luethi wrote:
> > Can you make an example? Some scenario where this would be important?
> 
> Not particularly. It largely means poorly-coded apps may report gibberish.

If we are still talking about the same thing here, gibberish is a rather
strong word. In the design I proposed access control affects the subset
of tasks returned as a result -- the tool would still display meaningful
information for the tasks it got replies for.

Anyway, if the access restrictions are hard-coded into the field ID,
then it's only the credentials that can change, and I can't see a race
there at the moment.

> On Tue, 14 Sep 2004 08:37:58 -0700, William Lee Irwin III wrote:
> >> Checking that system calls succeeded is a minimum requirement at all
> >> times. Misinterpreting error returns is the app's fault.
> 
> On Tue, Sep 14, 2004 at 06:01:50PM +0200, Roger Luethi wrote:
> > It's async. You can't rely on return values. They'd have to be in
> > netlink messages.
> 
> That's fine. Do these error messages specify which field access(es)
> caused the error?

They don't, because the access control I had in my dev tree silently
skipped tasks containing fields the process had no permission to read.
IOW, access control works as an implicit task selector. And security
wise that's clean because the kernel does not reveal any information
about other processes to the querying task (not even evidence of their
existence).

> Then assuming the error messages indicate which field access(es) caused
> the error(s), you're already done; userspace must merely retry the
> request with the offending fields cast out. Otherwise, you're still
> done: userspace can merely retry the field accesses one at a time
> (though it's nicer to say which ones caused the errors).

Agreed on every point.

The question I am pondering is: Does nproc need access control right now?
It's more work in kernel and user space and adds new opportunities to
introduce bugs. The merits seem rather dubious right now, considering
that all the fields used by current process info tools (files
/proc/pid{cmdline, stat, statm, status, wchan}) are world readable.
So my preference is to wait with access control until we know where
and how it is necessary.

Roger