Re: [PATCH 2/2] security.capability: fix conversions on getxattr

"Serge E. Hallyn" [off-list ref] writes:

On Thu, Jan 28, 2021 at 02:19:13PM -0600, Eric W. Biederman wrote:

quoted

"Serge E. Hallyn" [off-list ref] writes:

quoted

On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W. Biederman wrote:

quoted

Miklos Szeredi [off-list ref] writes:

quoted

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