Re: [nfsv4] allowed delayed writes via AUTH_GSS

[Carl Burnett <[e-mail]>]

In my earlier post, I was assuming the client already had successfully 
pushed dirty data back to the server using the user's authentication, 
which is what you really have to do.

But the client at some point will return the delegation if it has not 
already been revoked. For example if its recycling a vnode. That's really 
the case I was thinking about.

Carl

Carl Burnett
AIX Kernel Architecture - Network File System
[phone], TL 678-8498
(please reply to [e-mail])





Nicolas Williams <[e-mail]>
10/02/2003 12:46 PM

 
        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: [nfsv4] allowed delayed writes via AUTH_GSS



On Thu, Oct 02, 2003 at 07:17:59AM -0500, Carl Burnett wrote:
> Why wouldn't the client be able to use its host authentication (used in 
> SETCLIENTID) when doing DELEGRETURN? That seems like exactly what you 

Because that would also require that the client host have permission to
WRITE dirty buffers.  That's too much permission to grant implicitly to
client host principals, methinks.

Fortunately, delegation revocation is per-open file, not per-clientid.

So:

 - user goes away

 - clients keeps RENEWing using its hostbased principal creds

 - server recalls delegations

 - client can't flush dirty buffers or return the delegations

 - server revokes those delegations

 - user comes back, refreshes his/her creds, but finds that his/her app
   that had dirty state lost that state and got sent some signal that
   killed it (say, SIGLOST).

I think this is fine.

Though I think we could consider an operation that allows the user to
explicitly delegate to the client host permission to do DELEGRETURN and
WRITE on his behalf for his open files.

> 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.

What if the network goes away permanently?  That's pretty much the
effect of having the credentials of all involved go away permanently.

There's always going to be failure modes we can't easily recover from.
Even with plain AUTH_NONE and AUTH_SYS!  :)

Oh well.

> 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.

The more I think about it, the happier I am that delegations are
per-principal, rather than per-clientid.  That's because returning a
write delegation means writing dirty buffers and that's too much
permission to be implicitly granting to client host principals.

Cheers,

Nico
-- 




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