From: Albert Cahalan <albert@users.sf.net>
To: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>,
Andrew Morton OSDL <akpm@osdl.org>,
viro@parcelfarce.linux.theplanet.co.uk, pj@engr.sgi.com,
7eggert@gmx.de
Subject: Re: [PATCH][RFC] /proc umask and gid [was: Make /proc/<pid> chmod'able]
Date: Tue, 15 Mar 2005 23:31:14 -0500 [thread overview]
Message-ID: <1110947475.1967.280.camel@cube> (raw)
In-Reply-To: <20050316023923.GA27736@lsrfire.ath.cx>
On Wed, 2005-03-16 at 03:39 +0100, Rene Scharfe wrote:
> So, I gather from the feedback I've got that chmod'able /proc/<pid>
> would be a bit over the top. 8-) While providing the easiest and most
> intuitive user interface for changing the permissions on those
> directories, it is overkill. Paul is right when he says that such a
> feature should be turned on or off for all sessions at once, and that's
> it.
>
> My patch had at least one other problem: the contents of eac
> /proc/<pid> directory became chmod'able, too, which was not intended.
>
> Instead of fixing it up I took two steps back, dusted off the umask
> kernel parameter patch and added the "special gid" feature I mentioned.
>
> Without the new kernel parameters behaviour is unchanged. Add
> proc.umask=077 and all /proc/<pid> will get a permission mode of 500.
> This breaks pstree (no output), as Bodo already noted, because this
> program needs access to /proc/1. It also breaks w -- it shows the
> correct number of users but it lists XXXXX even for sessions owned
> by the user running it.
>
> Use proc.umask=007 and proc.gid=50 instead and all /proc/<pid> dirs
> will have a mode of 550 and their group attribute will be set to 50
> (that's "staff" on my Debian system). Pstree will work for all members
> of that special group (just like top, ps and w -- which also show
> everything in that case). Normal users will still have a restricted
> view.
>
> Albert, would you take fixes for w even though you despise the feature
> that makes them necessary?
I will take patches if they are not too messy and they do not
cause tools to report garbage output. For example, I do not
wish to have tools reporting -1, 0, or uninitialized data in
place of correct data.
Distinct controls for the various files could be useful.
I might want to make /proc/*/cmdline be public, or make
/proc/*/maps be private. This is particularly helpful if
a low-security file is added for bare-bones ps operation.
You might make a special exception for built-in kernel tasks
and init.
next prev parent reply other threads:[~2005-03-16 4:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-14 3:34 [PATCH][RFC] Make /proc/<pid> chmod'able Albert Cahalan
2005-03-14 9:42 ` Rene Scharfe
2005-03-14 16:13 ` Albert Cahalan
2005-03-14 23:08 ` Bodo Eggert
2005-03-15 2:44 ` Albert Cahalan
2005-03-15 10:51 ` Jonathan Sambrook
2005-03-15 14:31 ` Bodo Eggert
2005-03-15 15:29 ` Paul Jackson
2005-03-15 15:58 ` Albert Cahalan
2005-03-15 21:06 ` Bodo Eggert
2005-03-15 21:18 ` Rene Scharfe
2005-03-16 0:21 ` Kyle Moffett
2005-03-15 15:27 ` Rene Scharfe
2005-03-14 16:37 ` Pavel Machek
2005-03-16 2:39 ` [PATCH][RFC] /proc umask and gid [was: Make /proc/<pid> chmod'able] Rene Scharfe
2005-03-16 4:31 ` Albert Cahalan [this message]
2005-03-16 4:41 ` Albert Cahalan
2005-03-19 1:51 ` Rene Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1110947475.1967.280.camel@cube \
--to=albert@users.sf.net \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@engr.sgi.com \
--cc=rene.scharfe@lsrfire.ath.cx \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox