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

[Roger Luethi <rl@hellgate.ch>]

On Tue, 14 Sep 2004 00:10:58 -0700, William Lee Irwin III wrote:
> > - If the access control bits for a field are cleared, any process/user
> >   can get that field information for any process.
> > - If the access control bits are set to NPROC_PERM_USER, only root and
> >   the owner of a process can read the field for that process.
> > - For NPROC_PERM_ROOT, only root can ever read such a field.
> > I picked that design because it captures the essence of what /proc
> > does today.
> 
> The concern appears to be that the tools might interpret failed
> permission checks as indications of process nonexistence. I don't
> regard this as particularly pressing, as properly-written apps should
> check the specific value of errno (in particular to retry when EAGAIN
> is received in numerous contexts).

I would expect a tool to refrain from asking for fields with restricted
access if it needs a complete overview over existing processes. It can
always ask for restricted fields in a second request (the vast majority
of fields are world-readable anyway).

> > processes seems a good solution. In this special case, the current
> > nproc code returns 0, but that's probably not optimal. Currently,
> > my preferred solution would be to return ~(0).
> > I'm not convinced yet that making message formats more complex (adding
> > bitmaps or lists of applicaple fields or something) for one special
> > case is a better idea.
> 
> Distinguishing between EPERM, ENOSYS, ENOENT, etc. could probably be
> done if the fields are measured in units such that the top bit is never
> set for any feasible value, then a fully qualified error return could
> simply be returned as (unsigned long)(-err). I suspect VSZ may be
> problematic wrt. overflows even for 32-bit, not just for 31-bit.

Yeah, that makes me nervous. There are just too many ways this can go
wrong or be misinterpreted in user space. Currently, nproc does not
indicate the type of error at all, because a properly written user-space
app will either not hit an error or be able to figure out what the
problem was based on the available information. I suppose if we wanted
to change that (which doesn't sound unreasonable), the proper way would
be to return error flags with an error message (delivered via netlink).

Roger