From: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
To: Bodo Eggert <7eggert@gmx.de>
Cc: linux-kernel@vger.kernel.org,
Albert Cahalan <albert@users.sf.net>,
akpm@osdl.org, viro@parcelfarce.linux.theplanet.co.uk,
pj@engr.sgi.com
Subject: Re: [RFC][PATCH] Simple privacy enhancement for /proc/<pid>
Date: Mon, 11 Apr 2005 23:19:26 +0200 [thread overview]
Message-ID: <425AE9DE.5080407@lsrfire.ath.cx> (raw)
In-Reply-To: <Pine.LNX.4.58.0504101910270.4413@be1.lrz>
Bodo Eggert schrieb:
> On Sun, 10 Apr 2005, Rene Scharfe wrote:
>
>
>>First, configuring via kernel parameters is sufficient.
>
>
> I don't remember: Would a mount option be equally easy to implement?
> (Kernel parameters are OK for me, too.)
A mount option for procfs would be changable at remount, making
implementation a bit more involved.
>>I have another idea: let's keep the details of _every_ process owned by
>>user root readable by anyone.
>
>
> What about SUID processes acting on behalf of users?
SUID root processes will we visible for all, too. That's fair enough, I
think. If it's a concern to you use proc.privacy=2.
>>- processor.max_cstate= [HW, ACPI]
>>- Limit processor to maximum C-state
>>- max_cstate=9 overrides any DMI blacklist limit.
>>-
>
>
> This seems to belong into another patch
Strictly speaking, yes, but it's just a trivial cleanup near my own
change. And I guarantee it has zero impact on any built kernel image. :]
> (in pid_revalidate:)
> What about moving the things around? (just editing in the MUA)
>
>
>>+ if (IS_PID_DIR(proc_type(inode)) || task_dumpable(task)) {
>> inode->i_uid = task->euid;
>>+ inode->i_gid = proc_gid;
>>+ if (!proc_privacy || IS_PID_DIR(proc_type(inode)))
>> inode->i_gid = task->egid;
>> } else {
>> inode->i_uid = 0;
>> inode->i_gid = 0;
>> }
>> security_task_to_inode(task, inode);
>> return 1;
>> }
I suppose you could do that, but I don't see any gain. I also find my
version easier to read because it keeps the two conditionals (having
different intents and purposes) apart.
> BTW: You might be able to cache IS_PID_DIR(). It looks like being a gain.
I'd rather let the compiler do that job. It's only a small macro, I
really doubt you would measure any speedup from putting it into a local
variable.
>>@@ -1454,6 +1468,11 @@ static struct dentry *proc_pident_lookup
>
>
>>+ if (proc_privacy == 2 || task->euid != 0)
>
> ^^^^^
> redundand.
You're right and it's a matter of taste, I guess. By the way, this is
also what the FreeBSD crowd calls a "bikeshed". :-)
Thanks for reviewing my patch!
Rene
next prev parent reply other threads:[~2005-04-11 21:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-10 15:38 [RFC][PATCH] Simple privacy enhancement for /proc/<pid> Rene Scharfe
2005-04-10 18:07 ` Bodo Eggert
2005-04-11 21:19 ` Rene Scharfe [this message]
2005-04-12 5:29 ` Albert Cahalan
2005-04-12 21:16 ` 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=425AE9DE.5080407@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@engr.sgi.com \
--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.