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

From: [email-masked]
Date: Wed, 31 Aug 2005 11:11:11 -0400 (EDT)

[Dave wrote]
> 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.

Ok, what about the following sequence of client Ops done by ClientA:
- Open "foo" for reading and writing with cred for principalX
- server replies with StateidO-X and StateidWD-X (for a write delegation)
  - client allows local open by principalY for "foo" after checking access
    is permitted by:
	- Access Op
	OR
	- using the ACL in the Open reply that issued the delegation
- process that is running as principalX exits, so...
- Close "foo" using StateidO-X
- user that is principalX logs out, destroying cred for principalX
***

Now, to me, it seems like the following should still be allowed:
- Write of data for "for" using StateidWD-X for principalY
whereas it seems the proposal would require the client to do
- Open "foo" for reading and writing for principalY to get StateidO-Y
- Delegreturn StateidWD-X
at "***".

I think that when a network interconnect with significant delay is involved,
using delegations extensively "might" help w.r.t. performance. If you force
delegations to only work when the principal cred that did the Open that issued
the delegation exists, you strictly limit how long the delegation can persist.

Am I missing something here? rick

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

---

From: David Robinson <[email-masked]>
Date: Wed, 31 Aug 2005 10:39:51 -0500

>   - client allows local open by principalY for "foo" after checking access

This seems reasonable.

> 	- using the ACL in the Open reply that issued the delegation

This seems dangerous. The client cannot reliably determine the
permissions of principalY by just examining the ACL returned. Even
without close or logout of prinicpalX a subsequent operation
by principalY on file foo may unexpectedly fail because the
client could not fully evaluate the permissions.

> - Write of data for "for" using StateidWD-X for principalY

I agree, which is further reason why the ACCESS should be done
with principalY and the writeback done with StateidWD-X.

> Am I missing something here? rick

I don't think we have constructed delegations in a manner that
will allow delegation of trust back to the so for a principal that
has not previously OPEN'd a file we need an over the wire op.
(A better security person than I may correct me, but I think I
am right) So a delegation will save the case where a principal
repeatedly opens a file, but not a new principal.  But arguably
an ACCESS is lighter weight than an OPEN so there is still
some savings.

	-David