"Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > On Thu, Jan 28, 2021 at 02:19:13PM -0600, Eric W. Biederman wrote: >> "Serge E. Hallyn" <serge@xxxxxxxxxx> writes: >> >> > On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W. Biederman wrote: >> >> Miklos Szeredi <mszeredi@xxxxxxxxxx> writes: >> >> >> >> > If a capability is stored on disk in v2 format cap_inode_getsecurity() will >> >> > currently return in v2 format unconditionally. >> >> > >> >> > This is wrong: v2 cap should be equivalent to a v3 cap with zero rootid, >> >> > and so the same conversions performed on it. >> >> > >> >> > If the rootid cannot be mapped v3 is returned unconverted. Fix this so >> >> > that both v2 and v3 return -EOVERFLOW if the rootid (or the owner of the fs >> >> > user namespace in case of v2) cannot be mapped in the current user >> >> > namespace. >> >> >> >> This looks like a good cleanup. >> > >> > Sorry, I'm not following. Why is this a good cleanup? Why should >> > the xattr be shown as faked v3 in this case? >> >> If the reader is in &init_user_ns. If the filesystem was mounted in a >> user namespace. Then the reader looses the information that the > > Can you be more precise about "filesystem was mounted in a user namespace"? > Is this a FUSE thing, the fs is marked as being mounted in a non-init userns? > If that's a possible case, then yes that must be represented as v3. Using > is_v2header() may be the simpler way to check for that, but the more accurate > check would be "is it v2 header and mounted by init_user_ns". I think the filesystems current relevant are fuse,overlayfs,ramfs,tmpfs. > Basically yes, in as many cases as possible we want to just give a v2 > cap because more userspace knows what to do with that, but a non-init-userns > mounted fs which provides a v2 fscap should have it represented as v3 cap > with rootid being the kuid that owns the userns. That is the case we that is being fixed in the patch. > Or am I still thinking wrongly? Wouldn't be entirely surprised :) No you got it. Eric
