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

Roger Luethi
2004-09-14T06:47:24Z

On Sat, 11 Sep 2004 18:36:53 -0400, Albert Cahalan wrote:
> > I forgot to mention that you can see the remnants of that approach in
> > <linux/nproc.h>: I used two bits of the field ID to define per-field
> > access restrictions (NPROC_PERM_USER, NPROC_PERM_ROOT).
>
> Besides the low-security and high-security choices,
> I'd like to see a medium-security choice.
>
> low: everybody sees everything
> medium: everybody sees something; privileged user sees all
> high: must be privileged
>
> This might mean that asking for stuff like EIP and WCHAN
> causes you to see fewer processes.

I'm not sure I understand you correctly, but the combination of
NPROC_PERM_USER and NPROC_PERM_ROOT already seems to fit your
description:

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

> If partial info is returned for a process, I'd like to
> also get a bitmap of valid fields. Special "not valid"
> values are a pain to deal with.

If an app asks for a field it has no or partial permission for, the set
of processes returned is trimmed accordingly. Since an application will
expect this behavior based on the access control bits, no guessing is
involved here.

If an app asks for a non-existant field (not supported on this
architecture or obsolete), it will get an error back. No guessing
involved here, either. We could report the bad field ID back, but it's
easy for user-space to figure out and it's not in the fast path (for
user space).

The tricky case is if an app asks for an offered field without permission
problems, but the field is not available in that particular context. The
only instance of this that comes to mind are mm_struct related fields
and kernel threads. Neither returning an error nor skipping affected
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.

Roger