From: Al Viro <viro@ZenIV.linux.org.uk>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Daniel Reichelt <debian@nachtgeist.net>, linux-kernel@vger.kernel.org
Subject: Re: procfs: boot- and runtime configurable access mode for /proc/<pid> dirs
Date: Thu, 24 Mar 2011 18:44:17 +0000 [thread overview]
Message-ID: <20110324184417.GE22723@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20110324182230.GB5187@p183.telecom.by>
On Thu, Mar 24, 2011 at 08:22:30PM +0200, Alexey Dobriyan wrote:
> On Thu, Mar 24, 2011 at 09:41:58AM +0100, Daniel Reichelt wrote:
> > > Keeping u/g/o inside kernel is horrible.
> >
> > Why exactly? Since it's only a char and not char[] I don't see the
> > disadvantage over int or a define or whatever. Of course I could always
> > change that if that's a de-facto standard I just didn't know about.
>
> Keep mode_t inside kernel, this will get rid of many ifdefs.
>
> > > What is the usecase? Content of /proc/* is identical.
> >
> > Use-case is to isolate process information from other users' or groups'
> > eyes, e.g. with 550 the output of ps aux only lists processes of the
> > groups your user is a member of.
>
> This is doable with some ps(1) switch, I'm sure.
>
> The content of /proc/$PID directory is not a secret.
More to the point, permissions in /proc/<pid>/* don't do us much good.
As the matter of fact, we ought to make them all flat - i.e. same for
user/group/other, since we have to recheck access rights on every damn
IO operations. Checks done at open() are useless here - have the
task exec suid-root binary and they are obsolete.
next prev parent reply other threads:[~2011-03-24 18:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 4:09 procfs: boot- and runtime configurable access mode for /proc/<pid> dirs Daniel Reichelt
2011-03-24 7:32 ` Alexey Dobriyan
2011-03-24 8:41 ` Daniel Reichelt
2011-03-24 18:22 ` Alexey Dobriyan
2011-03-24 18:44 ` Al Viro [this message]
2011-03-24 18:49 ` Daniel Reichelt
2011-03-24 19:18 ` Daniel Reichelt
2011-03-24 20:37 ` Al Viro
2011-03-25 21:24 ` Christian Kujau
2011-05-26 10:56 ` Al Viro
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=20110324184417.GE22723@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adobriyan@gmail.com \
--cc=debian@nachtgeist.net \
--cc=linux-kernel@vger.kernel.org \
/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.