From: Roger Luethi <rl@hellgate.ch>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Albert Cahalan <albert@users.sf.net>,
Stephen Smalley <sds@epoch.ncsc.mil>,
Andrew Morton OSDL <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
Albert Cahalan <albert@users.sourceforge.net>,
Paul Jackson <pj@sgi.com>, James Morris <jmorris@redhat.com>,
Chris Wright <chrisw@osdl.org>
Subject: Re: [1/1][PATCH] nproc v2: netlink access to /proc information
Date: Tue, 14 Sep 2004 21:31:39 +0200 [thread overview]
Message-ID: <20040914193139.GA30827@k3.hellgate.ch> (raw)
In-Reply-To: <20040914190747.GA9106@holomorphy.com>
On Tue, 14 Sep 2004 12:07:47 -0700, William Lee Irwin III wrote:
> On Tue, Sep 14, 2004 at 08:45:18PM +0200, Roger Luethi wrote:
> > I suppose you are thinking of a request that lists a number of PIDs along
> > with a number of field IDs. In that case yes, I agree that it makes sense
> > to provide some explicit feedback to the tool once we add access control
> > (before that, there is no ambiguity: a missing answer means ESRCH).
> > The most common request, though, won't provide a list of pids, it will
> > only provide a list of field IDs and select all processes in the system
> > (NPROC_SELECT_ALL). There is no ambiguity here, either: The tool didn't
> > ask for any specific process to begin with, ESRCH doesn't make sense
> > here. And for a system that looks anything like /proc does today,
> > fields that are capable of triggering EPERM are few and far between,
> > certainly not something you are hitting unexpectedly in the fast path
> > of a process monitoring tool.
>
> Okay, so what kinds of errors are returned in this case, if any, or
> (worst case) are the offending tasks completely silently dropped?
In published code: No access control whatsoever. In dev tree: Silently
dropped. Possible: Any kind of error and additional information that
makes sense (we have netlink messages as a transport, after all).
That said, I don't think dropping tasks silently is a "worst case"
in this scenario. Whatever your error report is going to be, it will
boil down to saying "some tasks that may or may not live by the time
you read this have been skipped because some fields that you knew had
access restrictions prevented providing the information in those cases,
and I must be cautious about not revealing any sensitive information
to you so sorry I can't be more helpful". What's a tool going to do
with that? If it cares to get a complete snapshot, it can simply send
two requests: One with and one without restricted fields.
So the tool would, say, request PID/VmSize in the first message and
environ in the second message. Since only the owner can read the
environment, the second request would yield answers only for a subset
of the total process table.
Roger
next prev parent reply other threads:[~2004-09-14 20:11 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 18:40 [0/1][ANNOUNCE] nproc v2: netlink access to /proc information Roger Luethi
2004-09-08 18:41 ` [1/1][PATCH] " Roger Luethi
2004-09-09 0:35 ` William Lee Irwin III
2004-09-09 0:43 ` William Lee Irwin III
2004-09-09 1:15 ` William Lee Irwin III
2004-09-09 1:17 ` [1/2] rediff nproc v2 vs. 2.6.9-rc1-mm4 William Lee Irwin III
2004-09-09 1:21 ` [2/2] handle CONFIG_MMU=n and use new vm stats for CONFIG_MMU=y William Lee Irwin III
2004-09-09 1:22 ` William Lee Irwin III
2004-09-09 1:26 ` [3/2] round up text memory to the nearest page in fs/proc/task_mmu.c William Lee Irwin III
2004-09-09 18:43 ` [1/1][PATCH] nproc v2: netlink access to /proc information Roger Luethi
2004-09-09 18:49 ` William Lee Irwin III
2004-09-09 19:00 ` William Lee Irwin III
2004-09-09 19:02 ` [4/2] consolidate __task_mem() and __task_mem_cheap() William Lee Irwin III
2004-09-09 19:07 ` Roger Luethi
2004-09-09 19:15 ` [5/2] fix nommu VSZ reporting in consolidated task_mem() William Lee Irwin III
2004-09-09 19:11 ` [1/1][PATCH] nproc v2: netlink access to /proc information Roger Luethi
2004-09-09 19:23 ` William Lee Irwin III
2004-09-09 21:19 ` Roger Luethi
2004-09-10 15:30 ` Roger Luethi
2004-09-11 22:25 ` Albert Cahalan
2004-09-12 4:58 ` William Lee Irwin III
2004-09-14 5:59 ` Roger Luethi
2004-09-14 6:18 ` William Lee Irwin III
2004-09-14 6:23 ` William Lee Irwin III
2004-09-14 7:47 ` Greg Ungerer
2004-09-14 8:27 ` Roger Luethi
2004-09-09 11:53 ` Stephen Smalley
2004-09-09 17:22 ` William Lee Irwin III
2004-09-09 17:53 ` Roger Luethi
2004-09-09 20:01 ` Stephen Smalley
2004-09-09 20:48 ` Chris Wright
2004-09-10 12:11 ` Stephen Smalley
2004-09-09 20:55 ` Roger Luethi
2004-09-09 21:05 ` Chris Wright
2004-09-09 21:25 ` Roger Luethi
2004-09-11 22:36 ` Albert Cahalan
2004-09-12 5:00 ` William Lee Irwin III
2004-09-14 6:44 ` Roger Luethi
2004-09-14 7:10 ` William Lee Irwin III
2004-09-14 7:55 ` Roger Luethi
2004-09-14 8:01 ` William Lee Irwin III
2004-09-14 9:27 ` Roger Luethi
2004-09-14 15:37 ` William Lee Irwin III
2004-09-14 16:01 ` Roger Luethi
2004-09-14 16:37 ` William Lee Irwin III
2004-09-14 17:15 ` Roger Luethi
2004-09-14 17:43 ` William Lee Irwin III
2004-09-14 18:45 ` Roger Luethi
2004-09-14 19:07 ` William Lee Irwin III
2004-09-14 19:31 ` Roger Luethi [this message]
2004-09-14 19:36 ` William Lee Irwin III
2004-09-14 19:50 ` Roger Luethi
2004-09-15 11:44 ` Roger Luethi
2004-09-15 20:02 ` Roger Luethi
2004-09-15 20:20 ` William Lee Irwin III
2004-09-15 20:33 ` Roger Luethi
2004-09-15 20:44 ` Roger Luethi
2004-09-14 18:37 ` Chris Wright
2004-09-14 18:55 ` Roger Luethi
2004-09-14 19:05 ` Chris Wright
2004-09-14 21:12 ` Roger Luethi
2004-09-09 20:44 ` Chris Wright
2004-09-16 21:43 ` nproc: So? Roger Luethi
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=20040914193139.GA30827@k3.hellgate.ch \
--to=rl@hellgate.ch \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=albert@users.sourceforge.net \
--cc=chrisw@osdl.org \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=sds@epoch.ncsc.mil \
--cc=wli@holomorphy.com \
/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