On Thu, 21 May 2015 14:40:29 +1000
NeilBrown <neilb@xxxxxxx> wrote:
>
>
> Apologies if this has been answered before, however...
>
> In nfsd_write() we have:
>
> if (file) {
> err = nfsd_permission(rqstp, fhp->fh_export, fhp->fh_dentry,
> NFSD_MAY_WRITE|NFSD_MAY_OWNER_OVERRIDE);
> if (err)
> goto out;
> err = nfsd_vfs_write(rqstp, fhp, file, offset, vec, vlen, cnt,
> stablep);
> } else {
>
> So if a 'file' is already available - because the request came via NFSv4 and
> there was a valid state id, and a 'struct file' was associated with that
> state - we still call nfsd_permission().
>
> Is that really needed? The permission check will have been performed at open
> - it shouldn't be needed again now.
>
> With NFSv3 we have to check permission at each IO, and this is slightly
> different from POSIX semantics. We shouldn't have to with NFSv4... should we?
>
> The particular issue that brought this to my attention is that "chattr +i" -
> to make a file immutable - is not supposed to affect current opens, only
> future opens. But a current open over NFSv4 is affected.
>
> Is there some reason that we cannot just remove that nfsd_permission() check?
>
AIUI (maybe wrong), the stateid is mainly provided in WRITE for ordering
purposes (in case of another OPEN or OPEN_DOWNGRADE, or some locking is
also going on). From RFC5661:
Except when special stateids are used, the stateid value for a WRITE
request represents a value returned from a previous byte-range LOCK
or OPEN request or the stateid associated with a delegation. The
stateid identifies the associated owners if any and is used by the
server to verify that the associated locks are still valid (e.g.,
have not been revoked).
That last bit is the significant part here...
The actual info for the write itself is supposed to be given in other
fields.
While, it probably is a good idea for the server to verify that the
current_fh and the fh associated with the stateid actually match, you
can't really do that with the creds.
In short, READs and WRITEs are really still quite NFSv3-like in NFSv4...
--
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
Attachment:
pgp1C8E4aQbVI.pgp
Description: OpenPGP digital signature
