Re: [PATCH][RFC] Make /proc/<pid> chmod'able

[Rene Scharfe <rene.scharfe@lsrfire.ath.cx>]

Albert Cahalan wrote:
> This is a bad idea. Users should not be allowed to
> make this decision. This is rightly a decision for
> the admin to make.

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

> 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.
> 
> Let's not go there, OK?

I have to admit to not having done any real testing with those 
utilities.  My excuse is this isn't such a new feature, Openwall had 
something similar for at least four years now and GrSecurity contains 
yet another flavour of it.  Openwall also provides one patch for 
procps-2.0.6, so I figured that problem (whatever their patch is about) 
got fixed in later versions.

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?

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

Thanks for your comments,
Rene