From: Mike Eisler (mike@eisler.com)
Date: 10/02/03-12:14:39 PM Z
Message-ID: <3F7C5CFF.5080303@eisler.com> From: Mike Eisler <mike@eisler.com> Subject: RE: [nfsv4] allowed delayed writes via AUTH_GSS Date: Thu, 02 Oct 2003 10:14:39 -0700 > -----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
This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:47 AM Z CST