> If you don't use the same credentials used for the open() -- or, at
> [stuff snipped]

Yes, not using the Open credentials results in a non-POSIX compliant
file system. Every version of NFS including V4 is not POSIX compliant.

Although, in this case, I feel that using the Open cred. makes sense,
that is not what the RFC says:

	[para 4, pg 188]
	The stateid value for a READ request represents a value returned
	from a previous record lock or share reservation request. The stateid
	is used by the server to verify that the associated share
	reservation and any record locks are still valid and to update
	lease timeouts for the client.

As such, the RFC doesn't suggest the stateid can be used for file access
checking. In fact, the RFC never even suggests that this stateid need be
associated with an Open. (Indirectly, it turns out it does have to be
associated with an Open, due to the following statement in the description
of Close:
	[para 2, page 143]
	If record locks are held, the client SHOULD release all locks
	before issuing a CLOSE. The server MAY free all outstanding
	locks on CLOSE but some servers may not support the CLOSE of
	a file that still has record locks held. The server MUST return
	failure if any locks would exist after the CLOSE.

This one paragraph implies a rather complex hierarchial relationship
between Openowners, Opens, Lockowners and Locks that isn't really
discussed anywhere else in the RFC.

In summary, I don't think the RFC implies that the stateid should be
used to reference a related Open for file access checking. You can try
asking nfsv4@ietf.org, to see what they think.

At some point you just have to accept that NFS (even V4) is not fully
stateful and, as such, cannot be POSIX compliant.

Still, it's fun to try, rick