[RFC PATCH] lsm: fixup the inode xattr capability handling

[Serge E. Hallyn]

On Sat, May 04, 2024 at 04:26:24PM -0400, Paul Moore wrote:
> On May 4, 2024 1:04:57 PM Serge Hallyn <serge at hallyn.com> wrote:
> > Hm, so if it should happen that lsm 2 returns 0 (allow) but lsm 3
> > has skipcap return 3, and lsm 3 would have returned
> > 1 to deny the remove, we will get an unexpected result.  It feels like
> > we need a stronger tie between the lsm which allowed and the one
> > saying skip the capability check.
> 
> That's not an unexpected result, that is a valid outcome in the world of LSM
> stacking. The skipcap check only guarantees that the capability check will
> be skipped if an LSM returns a non-zero value.  The vast majority (all?) of
> the hooks operate as you describe: a LSM towards the back of the list can
> reject an operation that was previous LSM has allowed.  This isn't limited
> to LSMs either, there are plenty of reasons, e.g. transient failures, which
> could cause an operation to fail after being authorized by a particular LSM.
> 
> A particular LSM can only authorize a requested operation; a successful
> return value from a LSM hook implementation can not guarantee a successful
> operation result.

Ok, thanks.

-serge