From: ebiederm@xmission.com (Eric W. Biederman)
To: Michael Kerrisk <mtk-manpages@gmx.net>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
Kirill Korotaev <dev@openvz.org>,
Herbert Poetzl <herbert@13thfloor.at>,
Andrey Savochkin <saw@sw.ru>, Adrian Bunk <bunk@stusta.de>,
Cedric Le Goater <clg@fr.ibm.com>,
Chris Wright <chrisw@sous-sol.org>,
Stephen Smalley <sds@tycho.nsa.gov>,
James Morris <jmorris@namei.org>, Andrew Morgan <agm@google.com>
Subject: Re: CLONE_NEWUSER documentation
Date: Mon, 06 Aug 2007 00:48:47 -0600 [thread overview]
Message-ID: <m11wehkvjk.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <46B6C180.3020004@gmx.net> (Michael Kerrisk's message of "Mon, 06 Aug 2007 08:36:48 +0200")
Michael Kerrisk <mtk-manpages@gmx.net> writes:
>
> And again: is CLONE_NEWUSER (to be)implemented for unshare()?
They all should be. Only the pid namespace (not yet merged) looks
like a problem for unshare.
> Thanks Eric. I'm still not so clear though. What is a user name space
> intended to be, and how is it to be used?
>
> Also, when will the implementation be complete? If not by the 2.6.23 final
> release, it seems unfortunate to expose this flag to userspace, since
> further down the road, it will be difficult for userspace to tell whether
> the kernel below it really supports the flag or not. Or am I missing
> something?
Currently the code depends on CONFIG_USER_NS it is CONFIG_EXPERIMENTAL
and defaulting to N.
So no one should be shipping a production with it enabled, hopefully
that is enough, to avoid problems. I think the current implementation
is usable for some small subset of usable.
The basic idea is so that you have different mappings between uid and
gid values (i.e. /etc/passwd stuff) and struct user in the kernel.
Allowing the kernel to know two users with the same uid are distinct.
When you combined all of the namespaces (and when the are finished)
you have what is effective a chroot jail that looks like it has
the kernel all to itself despite other programs running.
Eric
next prev parent reply other threads:[~2007-08-06 6:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-05 9:35 Michael Kerrisk
2007-08-05 12:36 ` Eric W. Biederman
2007-08-06 6:36 ` Michael Kerrisk
2007-08-06 6:48 ` Eric W. Biederman [this message]
2007-08-06 13:09 ` 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=m11wehkvjk.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=agm@google.com \
--cc=bunk@stusta.de \
--cc=chrisw@sous-sol.org \
--cc=clg@fr.ibm.com \
--cc=dev@openvz.org \
--cc=herbert@13thfloor.at \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk-manpages@gmx.net \
--cc=saw@sw.ru \
--cc=sds@tycho.nsa.gov \
--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 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®