On Wed, Jul 20, 2016 at 2:52 PM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > It sounds like we need to remove the restriction on accessing the > filesystem from a different pid namespace. I don't think this poses a > security problem. However there's no pid mapping that is usable by the > userspace fuse process, so what do we put in the fuse request? Probably > the only candidates are 0 and 0xffffffff. > > So a question for the fuse developers - is one value or the other > preferrable for fuse_in_header.pid when the pid cannot be mapped, and is > this going to cause problems for any fuse filesystems? I suspect that > few filesystems actually look at the pid anyway, and already for a > filesystem mounted in a pid namespace the values being given to > userspace won't be correct for the namespace of the fuse process. pid = 0 sounds good. The pid from the request is used for example to get the auxiliary group list by libfuse (fuse_req_getgroups()). That's not used by all filesystems and it will return an error in case it can't find the proc entry (which it won't for pid == 0). It would be nice if we could transfer the group list through the userspace/kernel protocol, since then it wouldn't depend on proc and on being in the same pid namespace. But that's another story. 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
