Yes, for the time being the other metadata is i_ino, i_generation,i_uid, i_gid, and i_mode. The IMA-appriasal extension would store thefile hash as an extended attribute. The digital-signature extensionwould store a digitial signature instead of the hash.

> I'm not sure why it matters whether the selinux data has been written to> the buffers before the xattr containing the hash? The data will not> change (I hope!) and if it does presumably the hash will pick that up> when it is checked at a later date?

In this case it doesn't matter, as there aren't any other xattrs at thispoint. When the file closes, the file hash would be written out assecurity.ima, causing security.evm to be updated to reflect the change.

> The reason I'm asking is that currently the creation of GFS2 inodes is> broken down into a number of transactions, carefully designed to ensure> that the correct clean up occurs if there is an error. I would like to> try and reduce the number of transactions during the create process> where possible. That means I would like to move to a model which looks> like this:> > 1. Calculate number of blocks required, based on inode + xattrs (if any)> 2. Allocate blocks> 3. Populate with data (i.e. set xattrs)> > I'm trying to work out whether there is some reason why we have to use> your proposed:> > 1. Get selinux xattr> 2. Set selinux xattr> 3. Get EVM xattr> 4. Set EVM xattr> > as opposed to getting all the xattrs in a single call and then being> able to set them all in a single operation, if that makes sense?> > Steve.