From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Ian Kent <raven@themaw.net>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Cedric Le Goater <clg@fr.ibm.com>,
sukadev@us.ibm.com, Andrew Morton <akpm@osdl.org>,
Dave Hansen <haveblue@us.ibm.com>,
Herbert Poetzl <herbert@13thfloor.at>,
containers@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference
Date: Thu, 22 Mar 2007 13:07:07 -0500 [thread overview]
Message-ID: <20070322180707.GA15692@sergelap.austin.ibm.com> (raw)
In-Reply-To: <1174530523.4635.25.camel@raven.themaw.net>
Quoting Ian Kent (raven@themaw.net):
> How does this affect getting ids for waitq request packets of other user
> space processes triggering mounts? I'm guessing that they would need to
> belong to the appropriate namespace for this mechanism to funtion
> correctly.
A feature of the pid namespaces is that any process in a cloned
namespace still has a valid pid in all ancestore pid namespaces. So
when a process triggers a mount, either it is in the same or a decendent
pid namespace as the process which did the mounting, in which case the
pid sent to the mounter is correct; or it is in some other namespace,
and it will get '0'. The latter shouldn't happen in a proper setup, and
should be safe to ignore in an improper setup.
For instance, so long as any clone(CLONE_NEWPID) is always done along
with a CLONE_NEWNS, and process in the child namespace which mounts an
autofs instance, processes in the parent pid namespace won't trigger
automounts. But if somehow they did (i.e. with shared submounts or by
not doing CLONE_NEWNS), pid 0 will be reported.
thanks,
-serge
next prev parent reply other threads:[~2007-03-22 18:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 4:51 sukadev
2007-03-16 4:04 ` Ian Kent
2007-03-16 11:32 ` Eric W. Biederman
2007-03-16 14:31 ` Ian Kent
2007-03-16 14:44 ` Cedric Le Goater
2007-03-16 16:46 ` Ian Kent
2007-03-16 19:21 ` Eric W. Biederman
2007-03-19 20:08 ` Serge E. Hallyn
2007-03-19 20:40 ` Eric W. Biederman
2007-03-19 21:19 ` Serge E. Hallyn
2007-03-19 21:43 ` Eric W. Biederman
2007-03-20 20:15 ` Serge E. Hallyn
2007-03-20 20:45 ` Eric W. Biederman
2007-03-20 21:41 ` Serge E. Hallyn
2007-03-20 22:01 ` Eric W. Biederman
2007-03-21 20:58 ` Serge E. Hallyn
2007-03-22 2:28 ` Ian Kent
2007-03-22 14:33 ` Herbert Poetzl
2007-03-22 15:03 ` Ian Kent
2007-03-22 15:29 ` Eric W. Biederman
2007-03-22 15:22 ` Eric W. Biederman
2007-03-22 18:07 ` Serge E. Hallyn [this message]
2007-03-22 2:00 ` Ian Kent
2007-03-22 2:19 ` Serge E. Hallyn
2007-03-22 3:18 ` Ian Kent
2007-03-22 13:31 ` Serge E. Hallyn
2007-03-22 14:48 ` Ian Kent
2007-03-22 15:06 ` Ian Kent
2007-03-22 6:43 ` Eric W. Biederman
2007-03-22 13:28 ` Serge E. Hallyn
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=20070322180707.GA15692@sergelap.austin.ibm.com \
--to=serue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
--cc=sukadev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®