Re: [nfsv4] more re: ticket expiration and NFSv4 state

On Thu, Oct 02, 2003 at 05:30:22AM -0700, Talpey, Thomas wrote:
> At 12:44 PM 9/30/2003, Trond Myklebust wrote:
> >
> >     > it's my view that dirty data should not be written without the
> >     > explicit authentication under which the OPEN occured. e.g. in
> >     > the scenerio where the ticket has expired, the user loses the
> >     > data.
> >
> >     > this can all be mitigated by the client who's job it is to
> >     > track expiration times of gss_context's and prompt the user to
> >     > refresh creds so as not to get into this situation in the first
> >     > place.
> >
> >Why can't the client automatically flush out all dirty data and tear
> >down state on the user's behalf prior to the actual ticket expiration?
> 
> Why not, indeed. In fact, I would say it's the client's responsibility to do so,
> since we seem to be talking about kernels caching delayed writes on behalf
> of their authenticated users. The kernel is proxying for the user in this case,
> and must play be the same rules. If it delays writes that long, it needs to
> reauthenticate.

It's possible for the client to misjudge how much time it will need to
flush the dirty data, an untimely network failure could prevent it.

Credential expiration while holding dirty data for write delegations is
akin to a network failure.  The client can RENEW on behalf of its users,
but it can't WRITE or DELEGRETURN, so the server may end up revoking
write delegations, leading to loss of data on the client.

It's security vs. convenience, as Mike puts it.

Mike has described one possible compromise (using something like CCM to
establish client-user bindings) and I have described another (using a
new operation by which a user can explicitly delegate permission to
write/delegreturn on her behalf to the client).

Take your pick.  Myself, I think that the protocol as it stands is just
fine wrt credential expiration.

> That smart-card-user-on-vacation example got what he deserved, for
> instance.

Sure.

Cheers,

Nico
-- 

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