Re: [nfsv4] allowed delayed writes via AUTH_GSS

cburnett@us.ibm.com

Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS
Message-ID: <OF0A635B74.6783E3B7-ON87256DB3.0041158D@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Thu, 2 Oct 2003 07:17:59 -0500

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. Of course one barrier I see is that it takes a 
filehandle via PUTFH, and PUTFH will be checking the authentication 
against the allowed security flavors for the exported data. This is 
unfortunate since a client would like to be able to hang on to and manage 
its granted delegation across many opens for potentially many users. The 
client should not have to carefully watch all the authentication contexts 
for the accessing users in order to know that it must do a DELEGRETURN 
when the last related context is about to expire or be destroyed. And then 
what if an admin actually removes the principal from the KDC or some async 
event happens that makes the last applicable user context at the client 
unusable. Now you have a client holding a delegation that it can 
successfully return.

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.

Carl

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

Nicolas Williams <Nicolas.Williams@sun.com>
Sent by: nfsv4-admin@ietf.org
10/01/2003 11:57 PM

        To:     rick@snowhite.cis.uoguelph.ca, nfsv4@ietf.org
        cc: 
        Subject:        Re: [nfsv4] allowed delayed writes via AUTH_GSS

On Wed, Oct 01, 2003 at 04:01:36PM -0700, Nicolas Williams wrote:
> On Wed, Oct 01, 2003 at 06:44:31PM -0400, rick@snowhite.cis.uoguelph.ca 
wrote:
> > [Disclaimer: I'm far from a security or Kerberos wiz, so I might be
> >    way off the mark here.]
> > I've been thinking about delayed writes when using AUTH_GSS some more
> > and I think it might be ok in certain situations. (This would seem to
> > be nice, since clients with write delegations might delay the writes
> > for a very long time. It also gives the client a "more POSIX like"
> > semantic, since access is checked at Open only.)
> 
> I think a reasonable compromise is to allow the client's hostbased
> principal to renew state on behalf of its users, using the same
> CLIENTID.

And DELEGRETURN.  Unfortunately the client's hostbased principal will
generally not be able to perform a DELEGRETURN on behalf of its users.
Sigh.

Nico
-- 

_______________________________________________
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