Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1393075

Re: [PATCH 1/1] simplified security.nscapability xattr

From ebiederm@xmission.com (Eric W. Biederman)
Newsgroups linux.kernel
Subject Re: [PATCH 1/1] simplified security.nscapability xattr
Date 2016-05-03 08:10 +0200
Message-ID <ruBGY-2wf-19@gated-at.bofh.it> (permalink)
References (4 earlier) <rsjXQ-7jT-29@gated-at.bofh.it> <rudbA-4pM-3@gated-at.bofh.it> <rutT4-3cr-3@gated-at.bofh.it> <ruAKR-1EY-3@gated-at.bofh.it> <ruAUy-1JD-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Andrew G. Morgan (morgan@kernel.org):
>> 
>> I guess I'm confused how we have strayed so far that this isn't an obvious
>> requirement. Uid=0 as being the root of privilege was the basic problem
>> that capabilities were designed to change.
>
> The task executing the file can be any uid mapped into the namespace.  The
> file only has to be owned by the root of the user_ns.  Which I agree is
> unfortunate.  We can work around it by putting the root uid into the xattr
> itself (which still isn't orthogonal but allows the file to at least by
> owned by non-root), but the problem then is that a task needs to know its
> global root k_uid just to write the xattr.

The root kuid is just make_kuids(user_ns, 0) so it is easy to find.

It might be a hair better to use the userns->owner instead of the root
uid.  That would allow user namespaces without a mapped root to still
use file capabilities.

>> Uid is an acl concept. Capabilities are supposed to be independent of that.
>> 
>> If we want to support NS file capabilities I would look at replacing the
>> xattr syscall with a dedicated file capabilities modification syscall. Then
>
> That was one ofthe possibilities I'd mentioned in my earlier proposal,
> fwiw.  The problem is if we want tar to still work unmodified then
> simple xattr operations still have to work.
>
> Maybe there's workable semantics there though.  Worth thinking about.

If the problem is compatibilty please look at
posix_acl_fix_xattr_from_user.  With something similar for the
security.capability attribute we can perform whatever transformation
makes sense.  I admit adding 4 bytes is a bit of a pain in that context
but not a big one.

Eric

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 1/1] simplified security.nscapability xattr "Serge E. Hallyn" <serge@hallyn.com> - 2016-05-02 06:00 +0200
  Re: [PATCH 1/1] simplified security.nscapability xattr "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-05-02 20:40 +0200
  Re: [PATCH 1/1] simplified security.nscapability xattr ebiederm@xmission.com (Eric W. Biederman) - 2016-05-02 23:50 +0200
    Re: [PATCH 1/1] simplified security.nscapability xattr ebiederm@xmission.com (Eric W. Biederman) - 2016-05-03 07:10 +0200
      Re: [PATCH 1/1] simplified security.nscapability xattr "Serge E. Hallyn" <serge@hallyn.com> - 2016-05-10 21:10 +0200
    Re: [PATCH 1/1] simplified security.nscapability xattr "Serge E. Hallyn" <serge@hallyn.com> - 2016-05-03 07:20 +0200
      Re: [PATCH 1/1] simplified security.nscapability xattr ebiederm@xmission.com (Eric W. Biederman) - 2016-05-03 08:10 +0200
        Re: [PATCH 1/1] simplified security.nscapability xattr "Serge E. Hallyn" <serge@hallyn.com> - 2016-05-03 16:30 +0200
          Re: [PATCH 1/1] simplified security.nscapability xattr "Serge E. Hallyn" <serge@hallyn.com> - 2016-05-10 21:10 +0200
        Re: [PATCH 1/1] simplified security.nscapability xattr Jann Horn <jann@thejh.net> - 2016-05-08 01:10 +0200
          Re: [PATCH 1/1] simplified security.nscapability xattr "Serge E. Hallyn" <serge@hallyn.com> - 2016-05-11 23:10 +0200

csiph-web