Objections to Section 4.3.2 of integration-measurement-06 about i-d-integrity-measurement

[chucklever]

From RFC 5661:

5.5. Set-Only and Get-Only Attributes

Some REQUIRED and RECOMMENDED attributes are set-only; i.e., they can
be set via SETATTR but not retrieved via GETATTR. Similarly, some
REQUIRED and RECOMMENDED attributes are get-only; i.e., they can be
retrieved via GETATTR but not set via SETATTR. If a client attempts
to set a get-only attribute or get a set-only attributes, the server
MUST return NFS4ERR_INVAL.

15.1.6.1. NFS4ERR_ACCESS (Error Code 13)

Indicates permission denied. The caller does not have the correct
permission to perform the requested operation. Contrast this with
NFS4ERR_PERM (Section 15.1.6.2), which restricts itself to owner or
privileged-user permission failures, and NFS4ERR_WRONG_CRED
(Section 15.1.6.4), which deals with appropriate permission to delete
or modify transient objects based on the credentials of the user that
created them.

15.1.6.2. NFS4ERR_PERM (Error Code 1)

Indicates requester is not the owner. The operation was not allowed
because the caller is neither a privileged user (root) nor the owner
of the target of the operation.

15.1.6.3. NFS4ERR_WRONGSEC (Error Code 10016)

Indicates that the security mechanism being used by the client for
the operation does not match the server’s security policy. The
client should change the security mechanism being used and re-send
the operation (but not with the same slot ID and sequence ID; one or
both MUST be different on the re-send). SECINFO and SECINFO_NO_NAME
can be used to determine the appropriate mechanism.

The SETATTR operation is permitted to return:

NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, NFS4ERR_BADOWNER, NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, NFS4ERR_EXPIRED, NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_LOCKED, NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, NFS4ERR_UNKNOWN_LAYOUTTYPE, NFS4ERR_WRONG_TYPE

INVAL, ACCESS, and PERM are all permitted status codes, but WRONGSEC is not. In this case, I think allowing IMA metadata updates when the file content is writable, without any further adornment, is an adequate baseline.

[chucklever]

Possible alternative approach:

Typically, an NFS server allows a user to update IMA metadata whenever the user is permitted to modify the file's content. This is consistent with similar mechanisms already used throughout the NFS protocol.

If the user is not permitted to update the IMA metadata, SETATTR(FATTR4_IMA) MUST return NFS4ERR_PERM.

If the NFS server implementation does not support remote modification of IMA metadata, SETATTR(FATTR4_IMA) MUST return NFS4ERR_INVAL.