On Mon, 14 Mar 2005, Albert Cahalan wrote: > On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote: > > Albert Cahalan wrote:
> > Why do you think users should not be allowed to chmod their processes' > > /proc directories? Isn't it similar to being able to chmod their home > > directories? They own both objects, after all (both conceptually and as > > attributed in the filesystem). > > This is, to use your own word, "cloaking". This would let > a bad user or even an unauthorized user hide from the admin. NACK, the admin (and with the new inherited capabilities all users with cap_???_override) can see all processes. Only users who don't need to know won't see the other user's processes. > Note that the admin hopefully does not normally run as root. su1 and sudo exist. > Even if the admin were not running as a normal user, it is > expected that normal users can keep tabs on each other. > The admin may be sleeping. Social pressure is important to > prevent one user from sucking up all the memory and CPU time. Privacy is important, too. Imagine each user can see the CEO (or the admin) executing "ee nakedgirl.jpg". > > > Note: I'm the procps (ps, top, w, etc.) maintainer. > > > > > > Probably I'd have to make /bin/ps run setuid root > > > to deal with this. (minor changes needed) The same > > > goes for /usr/bin/top, which I know is currently > > > unsafe and difficult to fix. I used unpatched procps 3.1.11, and it worked for me, except pstree. > > Why do ps and top need to be setuid root to deal with a resticted /proc? > > What information in /proc/<pid> needs to be available to any and all > > users? > > Anything provided by traditional UNIX and BSD systems > should be available. e.g. the buffer overflow in sendmail? Or all the open relays? :) The demands to security and privacy have increased. Linux should be able to provide the requested privacy. > Users who want privacy can get their > own computer. So, these need to work: > > ps -ef > ps -el > ps -ej > ps axu > ps axl > ps axj > ps axv > w > top Works as intended. Only pstree breaks, if init isn't visible. > > > If you restricted this new ability to root, then I'd > > > have much less of an objection. (not that I'd like it) > > > > How about a boot parameter or sysctl to enable the chmod'ability of > > /proc/<pid>, defaulting to off? But I'd like to resolve your more > > general objections above first, if possible. :) I'd prefer a minimum and a maximum mask. If the admin wants to enforce privacy, he can do it, and if he wants the users to spy on each other, so be it. -- Top 100 things you don't want the sysadmin to say: 23. What do mean by "fired"? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
