From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: 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>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Bastian Blank <bastian@waldi.eu.org>
Subject: Re: [PATCH 03/08] allow sethostname in a container
Date: Fri, 4 Feb 2011 15:56:15 +0000 [thread overview]
Message-ID: <20110204155615.GA12062@mail.hallyn.com> (raw)
In-Reply-To: <20110111161431.GA1406@mail.hallyn.com>
Quoting Serge E. Hallyn (serge@hallyn.com):
> Quoting Serge E. Hallyn (serge@hallyn.com):
> > Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> > ---
> > kernel/sys.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/sys.c b/kernel/sys.c
> > index 2745dcd..9b9b03b 100644
> > --- a/kernel/sys.c
> > +++ b/kernel/sys.c
> > @@ -1171,7 +1171,7 @@ SYSCALL_DEFINE2(sethostname, char __user *, name, int, len)
> > int errno;
> > char tmp[__NEW_UTS_LEN];
> >
> > - if (!capable(CAP_SYS_ADMIN))
> > + if (!ns_capable(current->nsproxy->uts_ns->user_ns, CAP_SYS_ADMIN))
> > return -EPERM;
> > if (len < 0 || len > __NEW_UTS_LEN)
> > return -EINVAL;
> > --
> > 1.7.0.4
>
> An interesting note here is that since the task doing ns_exec (and
> therefore in the init_user_ns) requires CAP_SYS_ADMIN to unshare,
> this check will actually always be true if uts_ns was not unshared.
Noone ever called me on this, so for the sake of posterity reading the
m-l archives: what I said above is not true. If uts_ns was not
unshared, then current->nsproxy->uts_ns->user_ns != current_user_ns(),
so current should not have ns_capable(current->nsproxy->uts_ns->user_ns,
CAP_SYS_ADMIN). So the check will always return false.
> If uts is unshared, then regular capabilities semantics in the
> child user_ns apply (that is, root can do sethostname, unpriv user
> cannot) The intent is that user namespaces will eventually allow
> unprivileged users to unshare, after which this will make much more
> sense.
>
> -serge
next prev parent reply other threads:[~2011-02-04 15:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 6:43 userns: targeted capabilities v4 Serge E. Hallyn
2011-01-11 6:43 ` [PATCH 01/08] Add a user_namespace as creator/owner of uts_namespace Serge E. Hallyn
2011-01-11 6:44 ` [PATCH 02/08] security: Make capabilities relative to the user namespace Serge E. Hallyn
2011-01-11 6:44 ` [PATCH 03/08] allow sethostname in a container Serge E. Hallyn
2011-01-11 16:14 ` Serge E. Hallyn
2011-02-04 15:56 ` Serge E. Hallyn [this message]
2011-01-11 6:44 ` [PATCH 04/08] allow killing tasks in your own or child userns Serge E. Hallyn
2011-01-11 6:44 ` [PATCH 05/08] Allow ptrace from non-init user namespaces Serge E. Hallyn
2011-01-14 14:46 ` Bastian Blank
2011-01-14 15:00 ` Bastian Blank
2011-01-15 0:35 ` Serge E. Hallyn
2011-01-11 6:44 ` [PATCH 06/08] user namespaces: convert all capable checks in kernel/sys.c Serge E. Hallyn
2011-01-11 6:45 ` [PATCH 07/08] user namespaces: convert several capable() calls Serge E. Hallyn
2011-01-11 6:45 ` [PATCH 08/08] userns: check user namespace for task->file uid equivalence checks 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=20110204155615.GA12062@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=adobriyan@gmail.com \
--cc=bastian@waldi.eu.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=jmorris@namei.org \
--cc=kees.cook@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mtk.manpages@gmail.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;
as well as URLs for NNTP newsgroup(s).