On Wed, Mar 9, 2016 at 6:07 PM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > On Wed, Mar 09, 2016 at 04:51:42PM +0100, Miklos Szeredi wrote: >> On Wed, Mar 9, 2016 at 4:25 PM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: >> > On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote: >> >> >> Can't we use current_cred()->uid/gid? Or fsuid/fsgid maybe? >> > >> > That would be a departure from the current behavior in the !allow_other >> > case for unprivileged users. Since those mounts are done by an suid >> > helper all of those ids would be root in the userns, wouldn't they? >> >> Well, actually this is what the helper does: >> >> sprintf(d, "fd=%i,rootmode=%o,user_id=%u,group_id=%u", >> fd, rootmode, getuid(), getgid()); > > Sorry, I was thinking of euid. So this may not be a problem. > >> So it just uses the current uid/gid. Apparently no reason to do this >> in userland, we could just as well set these in the kernel. Except >> for possible backward compatibility problems for things not using the >> helper. >> >> BUT if the mount is unprivileged or it's a userns mount, or anything >> previously not possible, then we are not constrained by the backward >> compatibility issues, and can go with the saner solution. >> >> Does that not make sense? > > But we generally do want backwards compatibility, and we want userspace > software to be able to expect the same behavior whether or not it's > running in a user namespaced container. Obviously we can't always have > things 100% identical, but we shouldn't break things unless we really > need to. > > However it may be that this isn't actually going to break assumptions of > existing software like I had feared. My preference is still to not > change any userspace-visible behaviors since we never know what software > might have made assumptions based on those behaviors. But if you're > confident that it won't break anything I'm willing to give it a try. I'm quite confident it won't make a difference. Thanks, Miklos -- 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
