> On Feb 18, 2019, at 2:32 PM, bfields@xxxxxxxxxxxx wrote: > > On Thu, Feb 14, 2019 at 03:43:26PM -0500, Chuck Lever wrote: >> When NFSv4 Security Label support is enabled and kernel Integrity >> and IMA support is enabled (via CONFIG), then build in code to >> handle the "security.ima" xattr. The NFS server converts incoming >> GETATTR and SETATTR calls to acesses and updates of the xattr. >> >> The FATTR4 bit is made up; meaning we still have to go through a >> standards process to allocate a bit that all NFS vendors agree on. >> Thus there is no guarantee this prototype will interoperate with >> others or with a future standards-based implementation. > > Why the dependence on CONFIG_NFSD_V4_SECURITY_LABEL? Hrm, well there is some mechanism on the client side that IMA needs that is behind CONFIG_NFS_V4_SECURITY_LABEL. I guess I didn't think about not doing the same thing on the server. It may just be an artifact of an earlier version of this code. > (Also, I wonder if we actually need CONFIG_NFSD_V4_SECURITY_LABEL or if > we could just remove it, or replace it by CONFIG_SECURITY where > necessary.) On the server, there is already a (run-time) export option to enable and disable security labels. Is there a reason a distribution would want to disable client or server support for security labels at build time? -- Chuck Lever
