"Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > Quoting Andrew G. Morgan (morgan@xxxxxxxxxx): >> >> 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 -- 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
