Subject: RE: [nfsv4] Preview of new locking chapter

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 3 Aug 2006 14:54:04 -0400

I misunderstood you.  You are saying that the client
can use any credential, but probably should use the
one from the open.  That's not new and while the 
spec doesn't say that, it doesn't suggest otherwise.

The spec does say that the server can't assume that
the client will use the same credential, must handle 
it the client does a different credential and must do
the appropriate checking in that case.  I think that 
is compatible with what you are saying.  

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Thursday, August 03, 2006 2:31 PM
To: [email-masked]
Subject: RE: [nfsv4] Preview of new locking chapter

--- "Noveck, Dave" <[email-masked]> wrote:

> > The only requirement is that the cred of a file's opener,
> > be used on the operations of that file.
> 
> Right now the spec says the opposite, that any crendential
> may be used and is up to the server to do the apropriate checking.

If that's what the spec says it is very bad advice. Please
open an issue on it, and we'll fix it. But I don't think
anything I'm saying is new, or should be a surprise.

> So you are proposing that it be an error to do READ, WRITE, 
> or SETATTR, OPEN_DOWGRADE, CLOSE with an open stateid and 
> different credential.  Also open-upgrade with a different
> credential would return an error.  Correct?

No that's not what I'm saying. The client can certainly 
try any credential it wants, but if it wants correct POSIX
semantics, it shouldn't do that.

Most POSIX kernels keep the cred of the user than opened the file
with the file descriptor. That cred and not that of process
doing the system call, needs to be passed down to the NFS file system
on the client. In the case of OPEN_DOWNGRADE, the
principal doing the downgrade needs to have read access to the
file.

The case of a delegated file is different, but we have the
ACCESS operation to determine if the local process's OPEN would have
succeeded. If ACCESS works, then it is safe for the
process issuing the system call to use its own creds.

> Does the same hold for LOCK?  Must the crednetial be the same
> as the one that opened the file?  If that is not required,
> what about READ, WRITE with a lock stateid?

Yes.

> 
> Finally, there is the question of delegation stateids.  If
> you have a delegation, you may have a number of different
> users reading and writing the file as a result of opens, the

Yes, see the comments I made on ACCESS above.

> server doesn't see.  Also, the server can return a write 
> delegation on an open for read (based on previous access 
> patterns), so you may have a situation in which the user 
> doing the open is not allowed to write.  You would need to
> use a different credential to write the file that was
> delegated to the client as a whole.

That's a very interesting point. For the user doing the open() for
write on a file that was only open'ed for read, the NFSv4
file system should be issuing an ACCESS to see if the user
can WRITE. However, at some point, the data might be written to the
client while delegation is in force. Since there is a write delegation
in force, even though there is no OPEN for write, the server should
be smart enough to recognize that it is safe to accept WRITEs from
the delegate. However, what if the client originally OPENed the file
read-only by deny write? I don't know the answer to that one, but
I think it would be less confusing if the spec said that a
write delegate should have at least one OPEN for each type 
access (read or write) issued to the server before the 
corresponding READ or WRITE operation.
> 
> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 12:14 PM
> To: [email-masked]
> Subject: RE: [nfsv4] Preview of new locking chapter
> 
> 
> 
> 
> --- "Noveck, Dave" <[email-masked]> wrote:
> 
> > > It seems that there needs to continue to be the
> stateid/credential 
> > > association to protect against the denial of service that is
> > present.
> > 
> > The original denial-of-service concern was with respect to the 
> > owner sequence value which no longer exists, at least in part.
> 
> Correct.
> 
> > Given that v4.1 removes the owner sequence and the stateid sequence
> 
> > as denial-of-service targets, I think we should rethink this 
> > issue.  It still may be we want to go in this direction, but the
> > landscape has changed a bit, and I think with Mike's changes for
> > session, I don't think we have a denial of service issue.
> 
> I agree.
> 
> To solve the issue in NFSv4.0 one has to implement
> the server to bind the cred that OPENs the file
> to that which uses the open owner's sequence and the
> lock owner sequences.
> 
> As it stands now, the sequencing is exclusively in the SEQUENCE
> operation. With the introduction of the SSV concept,
> I've analyzed several ways an attacker could
> manipulate the slot table and disrupt other users of the
> session, and my conclusion is that connection hijacking is
> the only means possible. Even in NFSv3, connection hijacking can
> disrupt
> other users, even if RPCSEC_GSS with privacy is used. 
> Connection hijacking can only be foiled with IPsec.
> 
> Some form of stateid/credential association is nonetheless useful.
> Let's
> say user A opens a file, and then invokes a setuid
> program that takes the open file descriptor. The setuid program
> should be using A's credential in order to ensure that any
> I/O or lock operations it issues continue to work.
> 
> This is a client problem though. It needs to use the cred of the
> file opener, not that of the process doing the I/O.
> I believe most vnoded kernels do this anway.
> 
> Therefore, stateid/cred association comes for free. It also
> doesn't require the client maintain a separate open_owner
> for each cred; and open_owner can be shared across files and
> creds. The only requirement is that the cred of a file's opener,
> be used on the operations of that file.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

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