Re: procfs: boot- and runtime configurable access mode for /proc/<pid>dirs

[Daniel Reichelt]

>> Why exactly? Since it's only a char and not char[] I don't see the
>> disadvantage over int or a define or whatever. Of course I could always
>> change that if that's a de-facto standard I just didn't know about.
> 
> Keep mode_t inside kernel, this will get rid of many ifdefs.

Too obvious, point made.


>> Use-case is to isolate process information from other users' or groups'
>> eyes, e.g. with 550 the output of ps aux only lists processes of the
>> groups your user is a member of.
> 
> This is doable with some ps(1) switch, I'm sure.
> 
> The content of /proc/$PID directory is not a secret.

Sure, I could just run ps ux instead of ps aux and I'm done - in case I
wanna see only MY procs. That's my very point: sometimes it needs to be
a secret and not by ps-invoking-user's choice at that but by an admin's
enforcement. There are cases where I wouldn't want anybody ELSE to know
ANYTHING about my procs, not even their existence. So even when I'm root
on a box and I could restrict user-space tools...there's always another
unrestricted one. A curious user just compiles his own toy and goes fishing.

Real-world example: amongst many other (administrative) isolation
mechanisms to keep users apart, I've been using this approach for years
to enforce privacy in several hosting environments. Just think of poorly
implemented software which doesn't mask cmdline parameters like
--password. Of course one could argue "Just switch to another software."
Needless to say, that's often not option.
--
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/