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

[Roger Luethi]

On Tue, 14 Sep 2004 12:36:26 -0700, William Lee Irwin III wrote:
> On Tue, Sep 14, 2004 at 09:31:39PM +0200, Roger Luethi wrote:
> > In published code: No access control whatsoever. In dev tree: Silently
> > dropped. Possible: Any kind of error and additional information that
> > makes sense (we have netlink messages as a transport, after all).
> 
> I'm not sure what to make of this.

I was just trying to say that anything is possible (there are no
limitations inherent to the design), but I prefer it the way it is now.
I don't feel strongly about it should something different turn out to
be the preferred method of tool authors.

> This sounds safe enough, though it's unclear how to predict what fields
> may be restricted. I suppose one doesn't try and requests one field at

Simple: The fact that a field is subject to access restrictions is part
of the field ID. You can check that nproc.h contains this:

/* Access control (unused) */
#define NPROC_PERM_MASK		0x00300000
#define NPROC_PERM_USER		0x00100000
#define NPROC_PERM_ROOT		0x00200000

So even if a tool were to discover a new, previously unknown field offered
by the kernel, it could immediately tell that access restrictions apply and
what type they are (in case you wonder, there's extra space in reserve to
cover additional types of restrictions, including some catch-all thing (say
NPROC_PERM_COMPLEX_WHICH_MEANS_YOU_HAD_BETTER_KNOW_WHAT_YOU'RE_DOING)). So
nproc can cover everything /proc does today and is ready to go way beyond
that -- should that ever be deemed a good thing.

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