From: Andrew Morton <akpm@linux-foundation.org>
To: Mike McCormack <mikem@ring3k.org>
Cc: oleg@redhat.com, kosaki.motohiro@jp.fujitsu.com,
serue@us.ibm.com, jmorris@namei.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: Add complete process group list
Date: Tue, 22 Jun 2010 15:37:57 -0700 [thread overview]
Message-ID: <20100622153757.dcb6bda9.akpm@linux-foundation.org> (raw)
In-Reply-To: <4C20D1AE.5000205@ring3k.org>
On Wed, 23 Jun 2010 00:07:26 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> If a process is in more than NGROUPS_SMALL (32) groups, it's not possible
> for any other user space process to determine the list of groups it is
> in using /proc/<pid>/status.
>
> Increasing the list of groups listed by /proc/<pid>/status would lead to
> very long lines that file, and possible misbehavior of userspace programs
> that parse /proc/<pid>/status, so instead I have opted to create a new
> file /proc/<pid>/groups, which contains the list of supplementary groups
> for each pid.
>
> The new file /proc/<pid>/groups consists of a single group id per line,
> with each line being 11 characters long. This should be enough space
> for 16bit or 32bit group ids.
>
> This feature might be useful for a server listening on a unix domain pipe
> to determine the list of groups that a client process is in from its pid.
"might be"?
It would be useful to hear a bit more about usage scenarios, why this
is needed, etc - some hard info which would justify permanent extension
of the kernel->userspace API. How does this get used, why is it
needed, what are the alternatives, etc.
I don't recall having heard of anyone using the groups fields in
/proc/pid/status before.
next prev parent reply other threads:[~2010-06-22 22:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 15:07 [PATCH] proc: Add complete process group list Mike McCormack
2010-06-22 16:04 ` Oleg Nesterov
2010-06-22 22:37 ` Andrew Morton [this message]
2010-06-23 14:49 ` Mike McCormack
2010-06-24 2:41 ` KOSAKI Motohiro
2010-06-23 0:10 ` KOSAKI Motohiro
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=20100622153757.dcb6bda9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jmorris@namei.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikem@ring3k.org \
--cc=oleg@redhat.com \
--cc=serue@us.ibm.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 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.