From: ebiederm@xmission.com (Eric W. Biederman)
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
LSM <linux-security-module@vger.kernel.org>,
James Morris <jmorris@namei.org>,
Kees Cook <kees.cook@canonical.com>,
containers@lists.linux-foundation.org,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/4] Add a user_namespace as creator/owner of uts_namespace
Date: Fri, 10 Dec 2010 17:29:10 -0800 [thread overview]
Message-ID: <m1r5dpxfkp.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20101211005044.GA25513@p183.telecom.by> (Alexey Dobriyan's message of "Sat, 11 Dec 2010 02:50:44 +0200")
Alexey Dobriyan <adobriyan@gmail.com> writes:
> On Thu, Dec 09, 2010 at 05:20:27PM +0000, Serge E. Hallyn wrote:
>> struct uts_namespace {
>> struct kref kref;
>> struct new_utsname name;
>> + struct user_namespace *user_ns;
>
> You're going to add these to the rest?
That is the idea.
namespaces and other objects of interest will keep a user_ns
pointer referencing the context in which they were created.
I took a quick look and all of the namespaces seem to have capability
checks that we want to allow if you are in the proper context.
What is particularly interesting is that this makes a root user in
something other than the init_user_ns with all capabilities essentially
a normal user because capable(CAP_XXX) becomes capable(&init_user_ns, CAP_XXX).
And as such will always fail except where we have updated the capability
checks.
Eric
prev parent reply other threads:[~2010-12-11 1:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 17:20 [RFC PATCH 1/4] Add a user_namespace as creator/owner of uts_namespace Serge E. Hallyn
2010-12-09 17:28 ` [RFC PATCH 2/4] security: Make capabilities relative to the user namespace Serge E. Hallyn
2010-12-09 17:30 ` [RFC PATCH 3/4] allow sethostname in a container Serge E. Hallyn
2010-12-09 17:32 ` [RFC PATCH 4/4] allow killing tasks in your own or child userns Serge E. Hallyn
2010-12-10 11:16 ` Eric W. Biederman
2010-12-10 16:02 ` Serge E. Hallyn
2010-12-11 0:50 ` [RFC PATCH 1/4] Add a user_namespace as creator/owner of uts_namespace Alexey Dobriyan
2010-12-11 1:29 ` Eric W. Biederman [this message]
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=m1r5dpxfkp.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=jmorris@namei.org \
--cc=kees.cook@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge@hallyn.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