On Tue, 2011-12-06 at 11:04 -0600, Chandra Seetharaman wrote: > On Tue, 2011-12-06 at 11:30 -0500, Mimi Zohar wrote: > > On Tue, 2011-12-06 at 10:14 -0500, Christoph Hellwig wrote: > > > On Mon, Dec 05, 2011 at 12:42:21PM -0600, Chandra Seetharaman wrote: > > > > while running test case 234 from xfstests test suite, I was getting an > > > > occational memory fault in inode_has_perm() with the following stack > > > > > > Interesting. Given that have no good way to free other data with the > > > normal inode callback it looks like we indeed need to do this > > > separately. > > > > > > What about IMA or similar monsters? Posix ACLs already are covered at > > > least. > > > > Looks like a similar problem exists with the 'iint'. > > I walked thru the code and saw integrity_iint_find() is the one that > would be used to see if a iint data structure is associated. And, all > all the invocations of integrity_iint_find() check for NULL and handle > it properly. > > I might be wrong since I am not familiar with the code. Can you please > double check and let me know if I am wrong. > > Chandra The assumption up to this point has been that the iint will be freed only after the last call to ima_file_free(). The lack of an iint's existence indicates that the file is not in the measurement policy. As the iint is being freed, updating the iint flag is unnecessary for base IMA. However, in addition to updating the iint flags, the IMA-appraisal patches (yet to be upstreamed) update the 'security.ima' xattr. Without an iint, the xattr will not be updated. Mimi _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
