[manpages PATCH] capabilities.7: describe namespaced file capabilities
Serge E. Hallyn
serge at hallyn.com
Thu Apr 19 23:57:34 UTC 2018
Quoting Jann Horn (jannh at google.com):
> On Fri, Apr 13, 2018 at 9:26 PM, Michael Kerrisk (man-pages)
> <mtk.manpages at gmail.com> wrote:
> > Hello Serge, Jann,
> >>> Likewise,
> >>> +.BR getxattr(2)
> >>> +results will be converted and simplified to show a VFS_CAP_REVISION_2
> >>> +extended attribute, if a VFS_CAP_REVISION_3 applies to the caller's
> >>> +namespace, or to map the VFS_CAP_REVISION_3 root user ID into the
> >>> +caller's namespace.
> > I haven't captured that last paragraph in my text. I'm not sure I
> > understand the idea being presented. Serge, could you elaborate?
> Summary: When you read a capability attribute with getxattr(), the
> kernel will rewrite the returned value such that it looks the way it
> would have to look if the filesystem was mounted in your user
> namespace; just like how, when the attribute is written, the caller
> provides an attribute value written as if the filesystem was mounted
> in the caller's user namespace.
> Conceptually, this is mostly the same as the UID conversions applied
> by chown() and stat().
Right. If it is a V3, and the .rootid maps to a valid uid in your
namespace besides 0, then .rootid will be mapped to the valid user in your
namespace; if it is 0, then a V2 capability xattr will be presented.
If the real xattr is a V2, then a V2 is presented.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive