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

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 2 Oct 2003 05:30:22 -0700

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.

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

Tom.

>
>
>I don't think that the real problem is the case of ordinary ticket
>expiration, but rather the case where some process ends up revoking
>your credential without first notifying the NFS client.
>
>Cheers,
>  Trond
>
>_______________________________________________
>nfsv4 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Oct 2003 12:01:43 -0700

> and must play be the same rules. If it delays writes that long, it needs to

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

Sure.

Cheers,

Nico
--