Messages in this thread | | | Date | Mon, 14 Mar 2005 10:42:16 +0100 | From | Rene Scharfe <> | Subject | Re: [PATCH][RFC] Make /proc/<pid> chmod'able |
| |
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/
| |