Re: [nfsv4] allowed delayed writes via AUTH_GSS

Nicolas.Williams@sun.com

From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [nfsv4] allowed delayed writes via AUTH_GSS
Message-ID: <20031001230135.GC6829@binky.central.sun.com>
Date: Wed, 1 Oct 2003 16:01:36 -0700

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.

In fact, the protocol already allows this, I think.  So users with
expired creds on clients that have hostbased creds won't lose state, but
their dirty data won't be flushed either.   Oh well.

I think this is quite fine.

> [Nicolas Williams wrote]
> > It would still be nice for clients with hostbased princs/creds to be
> > able to flush dirty data using the clients' hostbased creds, which
> > requires binding of the clients' contexts to the same quantity.
> 
> Just suppose the following:
> 1 - Client does a SetClientID with AUTH_GSS, where the principal is
> 	nfs/host1@KERBEROS.REALM and gets clientid0
> 2 - Client Opens file "X" for writing, using clientid0 and AUTH_GSS, where
> 	the principal is <user>@KERBEROS.REALM successfully
> 	getting stateid0
> 3 - Client Writes to file "X" using stateid0 and AUTH_GSS, where the
> 	principal is nfs/host1@KERBEROS.REALM

> Now, if the principal nfs/host1@KERBEROS.REALM (which is the one the server saw
> for the SetClientID the Open is associated with) is considered acceptable, what
> vulnerabilities does that open up?

I don't think we can have the client's hostbased principal do anything
else that might be destructive on behalf of open owners authenticated
with different user principals.  But if we really wanted to do so we'd
have to address two thorny security issues: a) how do we identify which
principal the client can use for this, b) how do we make sure that all
these GSS contexts are sufficiently bound to the CLIENTID.  One
possibility might be to have a new operation by which a user could
delegate write/close/unlock authority to another principal.  But I don't
think we need go there if allowing the client hostbased principal to
renew state for its users, which I think it can.

Cheers,

Nico
-- 

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