RE: [nfsv4] allowed delayed writes via AUTH_GSS

cburnett@us.ibm.com

Subject: RE: [nfsv4] allowed delayed writes via AUTH_GSS
Message-ID: <OF6FB2C662.4EE438AE-ON87256DB3.0062E216@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Thu, 2 Oct 2003 13:26:27 -0500

I think this does represent a fairly serious problem with the protocol. 
You have situations where a client cannot return resources to a server. In 
the previously discussed cases of CLOSE and LOCKU, this potentially leads 
to the inability to access files because the client can't release state 
and there is no way short of manual intervention for the server to recover 
the resource. I am not referring the extreme cases where someone leaves an 
app running with opens and locks. Its the more typical cases where an 
application terminates, perhaps due to an EACCES upon loss of 
authentication, the client can't do its job. At least for the DELEGRETURN 
case the server can recall the delegation.

From a security perspective, I think you have to view it with a separation 
of the security around the file system resources that are being protected 
and the security around the client host to server host state management. 
The security of the file system resources is based on the real user 
accessing the files and enforcement of the access controls on them. That's 
different from the security of the client to server shared state. With 
SETCLIENTID, the protocol has already established that state control is in 
fact based on the security of SETCLIENTID. The problem is that the 
protocol operations for more granular state control have been coupled to 
file system export controls because of the use of the PUTFH operation.

As as been discussed, environments desiring stronger security beyond the 
protection of the data would probably want to leverage the use of 
RPCSEC-GSS on SETCLIENTID by creating a machine principal for the client. 
But history says many environments will not do this to reduce 
administration on the client side. They still get the strong security on 
the data, which is the key thing.

I am hoping for some good discussion on this topic at the upcoming 
bakeoff.

Thanks,
Carl

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

Mike Eisler <mike@eisler.com>
Sent by: nfsv4-admin@ietf.org
10/02/2003 12:14 PM

        To:     nfsv4@ietf.org
        cc: 
        Subject:        RE: [nfsv4] allowed delayed writes via AUTH_GSS

 > -----Original Message-----
 > From: Carl Burnett [mailto:cburnett@us.ibm.com]
 > Sent: Thursday, October 02, 2003 5:18 AM
 > To: nfsv4@ietf.org
 > Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS
 >
 >
 > Why wouldn't the client be able to use its host
 > authentication (used in
 > SETCLIENTID) when doing DELEGRETURN? That seems like exactly what you
 > would want to do.
[...]

 > To me, this looks fundamentally flawed that primarily state oriented
 > operations are so closely tied to user authentication when in
 > fact state
 > is a client to server. This is especially true for
 > delegations. Client IDs
 > own delegations, not users.

What you see as flawed, others might see as good security.

If one wants to compromise security for convenience, one has the
freedom to add an ACE to his files giving the SETCLIENTID
principal authority to write and read data. With that
authority, the client can then acquire, flush, and
return delegations via the machine cred. ACE inheritence from directories
deals with any of the ease of use issues this entails. The prescence
of the machine cred in the ACL informs the client to use this
capability.

Or simply concede that the pure
machine cred model is adequate for one's purposes and
implement/deploy my suggested GSS pseudo-mechanism.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4