Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces

[Serge E. Hallyn]

On Wed, Jul 29, 2015 at 11:04:50AM -0500, Serge E. Hallyn wrote:
> On Thu, Jul 16, 2015 at 12:04:43AM -0500, Eric W. Biederman wrote:
> > > I tend to thing that, if we're not honoring the fcaps, we shouldn't be
> > > honoring the setuid bit either.  After all, it's really not a trusted
> > > file, even though the only user who could have messed with it really
> > > is the apparent owner.
> > 
> > For the file caps we can't honor them because you don't have the bits
> > in struct cred.
> > 
> > For setuid we can honor it, and setuid is something that the user
> > namespace allows.
> 
> Setuid is something explicitly tied to the user id.  File capabilities
> are MAC, that is, explicitly orthogonal to user id.  So 100% agreed with
> honoring setuid in user_ns and, for now, ignoring file caps.

Hm.  No.  Seems like both should be fine when current is in the mounter's
user_ns, and ignored otherwise.

(The below is still needed :)

> As I've mentioned a few times privately, I'm intending to implement
> user-namespaced file capabilities as a new xattr.  Design is not 100%
> nailed down, but probably it would support a set of userns_fcaps, each
> of which lists the k_uid of the root user in the namespace assigning the
> filecaps, followed by three sets.  Then when exec()ing the file, if
> the current->userns->root user has a userns_fcap entry, or there is a -1
> entry, then use that, else use nothing.  I think this is a very importing
> thing to support, to remove a barrier to shipping packages with software
> using filecaps.  Without this, any package, say ping, which wants to
> support being installed in a (unprivileged) cotainer would need to also
> support use without filecaps, meaning that will likely be the only
> supported mode.
> 
> -serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/