linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: Stefan Berger <StefanBergerstefanb@linux.vnet.ibm.com>,
	ebiederm@xmission.com, containers@lists.linux-foundation.org,
	lkp@01.org, linux-kernel@vger.kernel.org,
	zohar@linux.vnet.ibm.com, tycho@docker.com, serge@hallyn.com,
	James.Bottomley@HansenPartnership.com,
	christian.brauner@mailbox.org, amir73il@gmail.com,
	linux-security-module@vger.kernel.org, casey@schaufler-ca.com
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Tue, 18 Jul 2017 07:48:49 -0400	[thread overview]
Message-ID: <20170718114849.GA8233@redhat.com> (raw)
In-Reply-To: <7a39e8a6-a33b-f6a8-3fd5-6211c075ab91@linux.vnet.ibm.com>

On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote:
> On 07/17/2017 02:58 PM, Vivek Goyal wrote:
> > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote:
> > 
> > [..]
> > > +/*
> > > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
> > > + *                             or determine needed size for attribute list
> > > + *                             in case size == 0
> > > + *
> > > + * In a user namespace we do not present all extended attributes to the
> > > + * user. We filter out those that are in the list of userns supported xattr.
> > > + * Besides that we filter out those with @uid=<uid> when there is no mapping
> > > + * for that uid in the current user namespace.
> > > + *
> > > + * @list:        list of 0-byte separated xattr names
> > > + * @size:        the size of the list; may be 0 to determine needed list size
> > > + * @list_maxlen: allocated buffer size of list
> > > + */
> > > +static ssize_t
> > > +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> > > +{
> > > +	char *nlist = NULL;
> > > +	size_t s_off, len, nlen;
> > > +	ssize_t d_off;
> > > +	char *name, *newname;
> > > +
> > > +	if (!list || size < 0 || current_user_ns() == &init_user_ns)
> > size will never be less than 0 here. Only caller calls this function only
> > if size is >0. So can we remove this?
> 
> Correct.
> 
> > 
> > What about case of "!list". So if user space called listxattr(foo, NULL,
> > 0), we want to return the size of buffer as if all the xattrs will be
> > returned to user space. But in practice we probably will filter out some
> > xattrs so actually returned string will be smaller than size reported
> > previously.
> 
> This case of size=0 is a problem in userns. Depending on the mapping of the
> userid's the list can expand. A security.foo@uid=100 can become
> security.foo@uid=100000, if the mapping is set up so that uid 100 on the
> host becomes uid 100000 inside the container. So for now we only have
> security.capability and the way I solved this is by allocating a 65k buffer
> when calling from a userns. In this buffer where we gather the xattr names
> and then walk them to determine the size that's needed for the buffer by
> simulating the rewriting. It's not nice but I don't know of any other
> solution.

Hi Stefan,

For the case of size==0, why don't we iterate through all the xattr,
filter them, remap them and then return the size to process in user
namespace. That should fix this? I thought that's what
xattr_list_userns_rewrite() was doing. But looks like this logic will not
kick in for the case of size==0 due to "!list" condition.

Also we could probably replace "!list" with "!size" wheverever required.
Its little easy to read and understand.

For the other case where some xattrs can get filtered out and we report
a buffer size bigger than actually needed, I am hoping that its acceptable
and none of the existing users are broken.

Thanks
Vivek

  reply	other threads:[~2017-07-18 11:48 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 15:05 [PATCH v2] Enable namespaced file capabilities Stefan Berger
2017-07-11 15:05 ` [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger
2017-07-11 17:12   ` Serge E. Hallyn
2017-07-12  0:15     ` Stefan Berger
2017-07-12  0:47       ` Serge E. Hallyn
2017-07-12  3:45   ` Serge E. Hallyn
2017-07-12 11:35     ` Stefan Berger
2017-07-12 17:32       ` Serge E. Hallyn
2017-07-12  7:59   ` James Morris
2017-07-12 13:25   ` Eric W. Biederman
2017-07-12 17:03     ` Serge E. Hallyn
2017-07-12 22:20       ` James Morris
2017-07-13  0:33         ` Eric W. Biederman
2017-07-13  1:01           ` Serge E. Hallyn
2017-07-12 23:13       ` Eric W. Biederman
2017-07-13  0:43         ` Serge E. Hallyn
2017-07-13  0:44         ` Stefan Berger
2017-07-13  1:15           ` Theodore Ts'o
2017-07-13  2:34             ` Serge E. Hallyn
2017-07-13 12:11             ` Eric W. Biederman
2017-07-13 16:40               ` Theodore Ts'o
2017-07-13 17:05                 ` Stefan Berger
2017-07-13 17:39                   ` Eric W. Biederman
2017-07-13 19:14                     ` Theodore Ts'o
2017-07-13 19:41                       ` Serge E. Hallyn
2017-07-13 21:17                     ` Serge E. Hallyn
2017-07-18  7:01                   ` James Morris
2017-07-18 12:12                     ` Stefan Berger
2017-07-18 13:26                       ` Eric W. Biederman
2017-07-18 23:13                         ` Serge E. Hallyn
2017-07-13 17:14                 ` Eric W. Biederman
2017-07-13 17:33                   ` Stefan Berger
2017-07-13 17:49                     ` Eric W. Biederman
2017-07-13 19:48                       ` Serge E. Hallyn
2017-07-13 21:12                         ` Eric W. Biederman
     [not found]                       ` <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com>
2017-07-14  0:38                         ` Eric W. Biederman
2017-07-14 11:32                           ` Stefan Berger
2017-07-14 12:04                             ` Eric W. Biederman
2017-07-14 12:39                               ` Stefan Berger
2017-07-14 13:34                             ` Serge E. Hallyn
2017-07-14 15:22                               ` Stefan Berger
2017-07-14 17:35                                 ` Serge E. Hallyn
2017-07-14 18:17                                   ` Eric W. Biederman
2017-07-14 18:48                                   ` Mimi Zohar
2017-07-14 18:52                                     ` James Bottomley
2017-07-14 20:03                                       ` Mimi Zohar
2017-07-14 20:39                                         ` James Bottomley
2017-07-14 21:34                                           ` Theodore Ts'o
2017-07-14 23:22                                             ` Eric W. Biederman
2017-07-14 23:29                                           ` Mimi Zohar
2017-07-14 23:53                                           ` Eric W. Biederman
2017-07-14 19:29                                     ` Theodore Ts'o
2017-07-14 19:43                                       ` Mimi Zohar
     [not found]                                   ` <xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com>
2017-07-14 19:26                                     ` Mimi Zohar
2017-07-15  0:02                                       ` Eric W. Biederman
     [not found]                                       ` <xagsmtp3.20170715001054.9173@uk1vsc.vnet.ibm.com>
2017-07-16 11:25                                         ` Mimi Zohar
2017-07-26  3:00                                       ` Serge E. Hallyn
2017-07-26 13:57                                         ` Mimi Zohar
2017-07-14 17:36                                 ` Eric W. Biederman
2017-07-14 19:22                                   ` Stefan Berger
2017-07-13 21:21                     ` Serge E. Hallyn
2017-07-13 21:13                 ` Serge E. Hallyn
2017-07-12 17:53   ` Vivek Goyal
2017-07-12 19:19     ` Stefan Berger
2017-07-14 23:41   ` Eric W. Biederman
2017-07-15 21:27     ` Stefan Berger
2017-07-17 18:58   ` Vivek Goyal
2017-07-17 20:50     ` Stefan Berger
2017-07-18 11:48       ` Vivek Goyal [this message]
2017-07-18 12:05         ` Stefan Berger
2017-07-18 12:30           ` Vivek Goyal
2017-07-18 12:36             ` Vivek Goyal
2017-07-18 13:29               ` Eric W. Biederman
2017-07-18 13:21             ` Stefan Berger
2017-07-18 14:57               ` Vivek Goyal
2017-07-18 16:11                 ` Stefan Berger

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=20170718114849.GA8233@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=StefanBergerstefanb@linux.vnet.ibm.com \
    --cc=amir73il@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=christian.brauner@mailbox.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=tycho@docker.com \
    --cc=zohar@linux.vnet.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;
as well as URLs for NNTP newsgroup(s).