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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
