Quoting Jann Horn (jannh@xxxxxxxxxx): > On Fri, Apr 13, 2018 at 9:26 PM, Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
