On Tue, Dec 12, 2017 at 10:04:56AM -0500, Mimi Zohar wrote: > On Tue, 2017-12-12 at 06:36 -0800, Christoph Hellwig wrote: > > On Tue, Dec 12, 2017 at 09:34:56AM -0500, Mimi Zohar wrote: > > > On Tue, 2017-12-12 at 06:26 -0800, Christoph Hellwig wrote: > > > > On Tue, Dec 12, 2017 at 09:21:09AM -0500, Mimi Zohar wrote: > > > > > Move the XFS_SB_MAGIC definition to magic.h. > > > > > > > > NACK. We want to keep the XFS code self-contained and no other part > > > > of the kernel has any business knowing it anyway. > > > > > > IMA policy rules can be defined in terms of magic numbers, but they > > > need to be defined in magic.h. Please reconsider... > > > > That is completely bogus, and it should not be supported in any way. > > File systems magic numbers are internal implementation details. > > Perhaps policies in general shouldn't differentiate between file > systems, but it definitely simplifies testing. How does specifying a filesystem type in a generic layer's policy implementation help testing? > For example, currently IMA-appraisal only supports storing file > signatures as xattrs, but support for appended signatures is being > added. Per file system rules could require different types of file > signatures. What's an "appended signature", and why is the filesystem independent xattr interface insufficient for storing this information? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
