Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

From: [email-masked]
Date: Tue, 30 Aug 2005 12:56:47 -0400 (EDT)

[I wrote]
> > I can think of a couple of things:
> > 1 - At one point, byte range Lock Op stateids were in the list for use
> >     in I/O Ops. I assume this would no longer be recommended practice?
> 
[Trond wrote]
> ??? Do you mean delegation stateids?

Actually, I was thinking of the stateid returned by a successful Lock Op.

As I see it, at any given time, a client can have up to 3 kinds of stateids
related to a file:
- open_stateid <-- returned by a Open Op
	(There can be several of these for the same file and using the
	 same or different credentials, for different open_owners.)
- delegation_stateid <-- returned by an Open Op if the server chooses to
	issue a delegation
- lock_stateid <-- returned by a Lock op
	(Again, there can be several of these, as above.)

Further, if the client has a delegation for the file, it might choose to
only retain that stateid and do opens and locking locally on the client.

As others have noted,
there is nothing in RFC3530 that defines which of these stateids should be used
for I/O ops. I vaguely recall an email thread that suggested an ordering by
priority, based on what the Solaris client does:
1 - delegation_stateid
2 - lock_stateid
3 - open_stateid
4 - special stateids (all 0s or all 1s)
(I might have the order wrong.)

Now, my understanding of Dave's interpretation of Garth's suggestion was
to require a client to use a credential for the same principal as an Open, as
identified by a stateid. I was trying to clarify which of the above stateids
would actually qualify. (It seems clear that if there are several open_stateids,
then any of them with the principal credential that was used for the Open that
returned that open_stateid would be ok, assuming the Open was for approriate
access.) It was not clear to me how the recommendation would apply to other
stateids?

[Trond wrote]
> Delegations can (and will) be forcibly revoked if a client doesn't want
> to give it back, so that is not really an issue here.

Yep, or the server could just choose to not issue delegations. I was just
trying to clarify the "what if the client has a delegation after doing
a Close Op on the open_stateid?" case.

Although I worded it poorly, it does seem like I stimulated a discussion
on the delegation_stateid case successfully, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: David Robinson <[email-masked]>
Date: Tue, 30 Aug 2005 16:44:09 -0500

> access.) It was not clear to me how the recommendation would apply to other

In the ordering above, each is derived from one another.  So my
interpretation of Garth's suggestion was to use the most specific
stateid that you have.  If you have a delegation stateid the file
was opened and at a minimum that stateid reflects the principal
used at the open. The client may have been avoiding locks because
of the delegation so the others may not be useable. Without a delegation
there may have been a lock operation which needs to be used because
it reflects the most recent lock state. In absence of locking then
the open_stateid needs to be used. Arguably in pNFS you may
prohibit special stateids.

But each of these stateids should be part of a chain of stateids
that all reflect the principal used on open. The OPEN returns the
open_stateid or optionally the delegation stateid, then those MUST
be used. If there is a lock operation, it should follow the same
principal as the open_owner and thus the lock stateid can be used.
What you don't want is to mix and match stateid chains and prinicpals.
I don't think 3530 does and mandating of prinicpal usage, but it
seems obvious that the client SHOULD use the same one that it used
to acquire the stateid, otherwise things may fail if the server
actually validates the operation.

	-David

---

From: eric kustarz <[email-masked]>
Date: Tue, 30 Aug 2005 18:17:48 -0700

>(I might have the order wrong.)

In case you wondering, that is the correct ordering for the Solaris client.

eric