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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 31 Aug 2005 10:09:35 -0400

> Yes and no. Even RFC3530 appears to imply that a client should always
> call OPEN and/or ACCESS in order to verify that it has sufficient
> privileges to access the file. I don't see how anyone could interpret
> this as being optional behaviour.

Where does it imply this?  I have scanned the spec for the word "ACCESS"
and didn't see any statement like this, so I don't think it states it.
Where do you derive the implication?  In fact, the treatment of ACCESS
implies the reverse.  ACCESS is presented as something you do if you 
want to check whether you have permission to do some operation on a file,
e.g. READ or WRITE, without actually doing the access.  The implication
is that if you are OK with trying the operation instead then you can do 
that and deal with the error, and therefore that the server is obliged
to check when the IO is done.

I think it is implied that if the client is handing out data without doing
an IO operation, e.g. from the data cache, it needs to verify that the 
principal who is recieving it internally has been validated for the
appropriate access to that file, either by an OPEN, ACCESS, or the 
ace information in a delegation.  I think that is implied by the requirement
to check access for the IO operation itself so that any transfer of that
information to a different principal would require validation of that
principals right to access it or else nfs security is a dead letter.  

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Wednesday, August 31, 2005 2:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

ty den 30.08.2005 Klokka 22:34 (-0700) skreiv Mike Eisler:
> Stateids are shorthands for open owners and lock owners, where an open owner
> and lock owner is not necessarily tied to one principal. Nor are the stateids
> necessarily tied to a file, or an open file reference.  The stateid's purpose
> is to indicate open, delegation and byte range lock state. Stateids are very
> abstract, perhaps underspecified, which has led to at least two opposed,
> but arguably both valid, interpretations of stateids.

Yes and no. Even RFC3530 appears to imply that a client should always
call OPEN and/or ACCESS in order to verify that it has sufficient
privileges to access the file. I don't see how anyone could interpret
this as being optional behaviour.
IOW: every stateid transition is supposed to be authenticated by the
metadata server, and it does not appear to be possible for a client to
just assume that it can just gratuitously switch to using a principal
that has not previously been authenticated by an OPEN.

The main argument in this thread appears rather to be whether or not a
server can assume that the client will associate a single principal to
each stateid, or if the server would have to track several principals in
order to map a stateid into an access.

> A file descriptor is a shorthand for "the principal that opened the file".

...but if you tie the lifetime to that of the stateid (you state that
the descriptor is only destroyed at CLOSE) how does that improve the
server's ability to cache authorisation information?

Couldn't you obtain similar performance if you use a scheme where the
server just pushes the principal for every successful OPEN (or if the
client has a delegation: for every ACCESS) to the data servers, which
then caches the result and then reaps the cache upon
CLOSE/OPEN_DOWNGRADE or SETATTR?

Cheers,
  Trond

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 31 Aug 2005 08:41:50 -0700

> principals right to access it or else nfs security is a dead letter.  

Isn't a client always required to ensure it has the correct share
reservations on the file? Section 8.10 certainly appears to imply this.
How can it do so without calling OPEN (except when holding a delegation,
in which case section 9.4 applies)?

Cheers,
  Trond