All of lore.kernel.org
 help / color / mirror / Atom feed
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.



  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.