Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS

From: Carl Burnett <[email-masked]>
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 [email-masked])

Nicolas Williams <[email-masked]>
Sent by: [email-masked]
10/01/2003 11:57 PM

        To:     [email-masked], [email-masked]
        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, [email-masked] 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Oct 2003 10:46:37 -0700

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

> unusable. Now you have a client holding a delegation that it can 

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.

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