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

[William Lee Irwin III]

On Sat, 11 Sep 2004 18:36:53 -0400, Albert Cahalan wrote:
>> This might mean that asking for stuff like EIP and WCHAN
>> causes you to see fewer processes.

On Tue, Sep 14, 2004 at 08:44:03AM +0200, Roger Luethi wrote:
> 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.

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


On Sat, 11 Sep 2004 18:36:53 -0400, Albert Cahalan wrote:
>> 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.

On Tue, Sep 14, 2004 at 08:44:03AM +0200, Roger Luethi wrote:
> 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.

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.


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