Subject: [nfsv4] pNFS, OPEN principals and ACLs

From: Garth Goodson <[email-masked]>
Date: Mon, 29 Aug 2005 10:31:32 -0700

For 4.1 and as a dependency for pNFS, I would like to propose that the 
principal used for OPEN is the same principal as used for I/O.

This has been brought up a number of times and as currently worded 
within the v4 spec (no requirement that READs and WRITEs issued for an 
open file have the same credentials as the OPEN itself) poses undue 
overhead on the data servers to access check each I/O based on the 
principal within the operation against all principals within the ACL. 
It also means that ACL changes must be propagated synchronously to each 
data server.

If this restriction is lifted, the data server need only check that the 
correct principal is using the stateid -- no other checks are needed. 
Also, when the ACL changes, the metadata server would either recall the 
layout or update its state reflecting the privileges associated with 
that principal.

-Garth

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

---

From: [email-masked]
Date: Mon, 29 Aug 2005 15:01:05 -0400 (EDT)

> principal used for OPEN is the same principal as used for I/O.

Just a minor nit. I assume that if there are multiple Opens for the file
held by the client for that kind of access, that the credential used for any of
these Opens is acceptable?

rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 29 Aug 2005 15:12:41 -0400

I believe Garth is saying that the one used must match the 
stateid, i.e. that it must have been the principal that did
the open that produced that stateid.

For IO with special stateid's, I would assume that the server
would have to check the ACL on each request.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Monday, August 29, 2005 3:01 PM
To: [email-masked]
Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

Just a minor nit. I assume that if there are multiple Opens for the file
held by the client for that kind of access, that the credential used for
any of
these Opens is acceptable?

rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 31 Aug 2005 14:47:02 -0400

> Sessions has perhaps emerged as the most important feature on the
table 
> right now. 

Yes, but as you indicate below a lot of that importance derives from the
fact that it would be a prereq for other features important in their 
own right.

> It seems it offers the broadest set of potential benefits (DOS 
> protection, performance/scaling efficiencies, exactly once semantics),
and 
> it seems to be often an assumed prereq for other NFS features (pNFS, 
> optimized RDMA). I am a big proponent of directory delegation, but I
would 
> have to concede that sessions looks more critical for advancing the
state 
> of NFSv4 near term.

I agree that if it were one or the other, directory delegations would be
the one to be thrown out of the lifeboat, but I don't think that is the
situation.

> Maybe if NFS 4.1 were limited to only sessions, it could reach
consensus 
> quicker and therefore show up in products sooner. Then there would be
a 
> foundation for bringing in the other features. 

I think that might have been a viable approach a year or so ago.  At
this
point, I believe it would be counter-productive.  In particular,
although 
we could reach consensus on v4.1 quicker (assuming that we could reach
consensus on the sessions-only approach), I don't think that overall,
this would result in products all that much sooner.

While we can look at the many benefits that sessions would bring to the
protocol, I don't see that people outside the working group would agree.
Let's face it.  We're protocol geeks and what (justifiably) impresses
us does not really move those making investment and deployment
decisions.
For v4.1 to make a relatively quick transition to real use requires a 
marquee feature like pNFS if that is at all possible to incorporate.  I
would argue that even though pNFS would slow the v4.1 spec somewhat, it
would accelerate actual deployment of sessions, even ahead of pNFS
implementations.

> To make it easier to bring 
> in follow-on features, maybe 4.1 could also include some type of
generic 
> plug-in facility that allows dynamic insertion of new NFS features
without 
> requiring a formal rev of the NFS protocol itself.

I'd need some details on this.  It sounds like it could bring serious
interoperability problems in its wake.  As we strived to get features
out
more quickly without the review implied by the curreng spec process, I
would be very afraid of the prospect of an interoprability minefield.

Besides if you are worried about getting v4.1 faster, I would say that
trading directory delegations for a general protocol exensibility
feature
is a bad trade.  Directory delegations has a detailed draft and as far 
as I know no current open issues (although there remains some
lukewarmness 
about notifications). This general extensibility feature is not even
near
to be specified concretely and I'm sure that there are many different 
opinions about its general desirability (I have had three and that's
just
in the last fifteen minutes). 

-----Original Message-----
From: Carl Burnett [mailto:[email-masked]] 
Sent: Wednesday, August 31, 2005 11:23 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

Hi Mike,

The getfd/putfd idea sounds interesting. Could the getfd be something
that 
the server optionally supplies? The thought is that if the server has 
efficient means to quickly determine access from only the filehandle and

auth_context, it might want opt out of supplying the fd to the client
and 
just do its normal access processing on the i/o ops. Also, the server
may 
have security policies beyond the basic access controls on the file - 
things like time of day restrictions, etc. Similarly, the client's use
of 
GETFD might also be optional.

While this might be pretty cool, In the big picture, this seems like a 
lower priority item. Its a performance tweak.

Sessions has perhaps emerged as the most important feature on the table 
right now. It seems it offers the broadest set of potential benefits
(DOS 
protection, performance/scaling efficiencies, exactly once semantics),
and 
it seems to be often an assumed prereq for other NFS features (pNFS, 
optimized RDMA). I am a big proponent of directory delegation, but I
would 
have to concede that sessions looks more critical for advancing the
state 
of NFSv4 near term.

Maybe if NFS 4.1 were limited to only sessions, it could reach consensus

quicker and therefore show up in products sooner. Then there would be a 
foundation for bringing in the other features. To make it easier to
bring 
in follow-on features, maybe 4.1 could also include some type of generic

plug-in facility that allows dynamic insertion of new NFS features
without 
requiring a formal rev of the NFS protocol itself.

Just a thought,
Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

Mike Eisler <[email-masked]> 
Sent by: [email-masked]
08/30/2005 10:22 PM
Please respond to
email2mre-ietf

To
[email-masked]
cc

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

> I don't view the current model as a mistake. It enhances the potential

> scalability of the protocol's state model and allows the client to 
> contribute in scalable state management. The lack of a secure token in

the 
> RPC transactions that ties directly to a clientid instance is a 
> deficiency. The potential good news is that Tom Talpey believes
sessions 

> can effectively fix that issue.

This is as good as time as any to talk about this ...

One of the problems with NFSv4.0 is vulnerability to a Denial of Service
attack via seqids.

Namely, the attack works via an unauthorized client faking an
open_owner4, an open_owner/lock_owner pair, or stateid, combined
with a seqid. The operation is sent to the NFSv4 server.
The NFSv4 server accepts the state information, and
as long as any status code from the result of this
operation is not NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR,
NFS4ERR_RESOURCE, or NFS4ERR_NOFILEHANDLE, the sequence
number is incremented. When the authorized client issues
an operation, it gets back NFS4ERR_BAD_SEQID, because
its idea of the current sequence number is off by one.
The authorized client's recovery options are pretty
limited, with SETCLIENTID, followed by complete reclaim
of state, which may or may not succeed completely.
That qualifies as a denial of service attack.

Even if the data is exported with RPCSEC_GSS
protection, the attacker can use RPCSEC_GSS to make this attack work. If
he creates an RPCSEC_GSS context from a synthetic client, nothing
prevents him from constructing a COMPOUND that uses a valid
stateid and seqid for some operation. 

(I am assuming if the problem can be solved when using RPCSEC_GSS,
then the problem is solved; AUTH_SYS doesn't matter, because
AUTH_SYS is merely a large security hole.)

We could handle client and server behavior such that clients map
each open_owner and lock_owner to one any only one principal,
and servers enforce this. However not all clients are ready
for this, and Carl has noted the scalability issues that would
hinder implementing such behavior.

The NFSv4.1 sessions work provides an excellent architecture
for solving this. Namely, with sessions, there are no 
per operation seqids. There is a per
COMPOUND SEQUENCE operation tied to a real session and clientid.
Much simpler to implement, and as I'll claim in a bit, much easier
to secure.

The denial of service attack on sessions would need to forge 
the sessionid in a SEQUENCE operation in order to mess up the 
sequence number state. While possible based
on the sessions I-D (as currently written) such an attack is going to
be more obvious to an NFSv4.1 client and server. Still we can do better.

What we want to do is bind an RPCSEC_GSS context to a clientid. My 
proposal
is a BIND_CTX_TO_CLID operation that takes as input an RPCSEC_GSS
context 
handle from
an establish RPCSEC_GSS context. BIND_CTX_TO_CLID is a new sessions op;
it 
MUST be
preceded by the SEQUENCE operation, which in turn MUST be the first
op in a COMPOUND. The procedure MUST be invoked with RPCSEC_GSS
integrity 
or
privacy. The principal that issues the COMPOUND with 
  { SEQUENCE, BIND_CTX_TO_CLID }
is that of the principal that created the clientid and session.

So what does this do? If an attacker creates an RPCSEC_GSS 
context and issues a COMPOUND with SEQUENCE and a valid sessionid, 
the server denies the access, because the context is not bound to 
the clientid. If the attacker spoofs a valid RPCSEC_GSS context 
handle, because he doesn't have the RPCSEC_GSS session key for
the clientid creating principal, he is denied.

So the denial of service described above is defeated.

What of the issue Garth raised? I propose that we introduce
two new operations, GETFD and PUTFD. Like GETFH, GETFD is invoked in the
same COMPOUND as OPEN, after OPEN. GETFD returns a file descriptor.
PUTFD injects a file descriptor. Unlike file handles, file descriptors
do not persist. One a file is CLOSEd, the file descriptor used
in the CLOSE is disposed of. PUTFD is used for any operation on
a regular file that takes a stateid. PUTFD is used instead of PUTFH.

If a client does a GETFD, the server returns the file descriptor, and 
binds
the principal of the user that issued the OPEN to the file descriptor. 
The server records in its memory the principal and the access rights 
(read, write, or
both) that the principal was allowed to do at the time of the OPEN.

Thereafter, use of the file descriptor on any operation on a
regular file does not require an access check. As long as the
principal matches, and the operation matches the access rights, the
operation is permitted.

GETFD can also be used after an ACCESS call. Thus if an OPEN that does
delegation is done, the client can issue an ACCESS request if a
different
principal attempts to access the file internally. CLOSE is again used to

dispose
of a file descriptor.

If we have file descriptors, why do we still need file handles? We need 
them
for caching. File descriptors don't last, whereas file handles,
especially
persistent file handles, last a long time. Without file handles, it is
not
practical to do long term caching of data.

---

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

[I wrote]
> > 	OR
> > 	- using the ACL in the Open reply that issued the delegation
> 
[Dave wrote]
> 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.

I suspect you are correct wr.t. current implementations.. I vaguely recall
asking what the ACL in the
write delegation should look like, back when I was first implementing
delegations, and there didn't seem to be much consensus w.r.t. it.

Having said that, the RFC seems pretty clear [from Sec. 14.2.16]:
           nfsace4         permissions;    /* Defines users who don't
                                              need an ACCESS call as
                                              part of a delegated
                                              open. */

rick