![]() | |||||||||||||
Messages in this thread |
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
| ||||||||||||
| Last update: 2005-03-22 14:11 [from the cache] ©2003-2008 | |||||||||||||