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

From: [email-masked]
Date: Mon, 29 Sep 2003 18:58:05 -0400 (EDT)

>> I think that a server may want to require something more than AUTH_SYS.
>
>What if my client doesn't have a krb5 or public key
>infrastructure handy?

Then you might or might not be allowed to SetClientID, based upon what
the sysadmin has put in the exports file and your ip#. (It still seems
to me that, if the server is willing to accept SetClientID from a machine
using AUTH_SYS, it might as well accept LOCKU and CLOSE via AUTH_SYS from
the same machine. As you pointed out, the client chose to use AUTH_SYS and
should accept the risk.)

>> Like Dave, it seems to me that the principal that is allowed to do
>> a SETCLIENTID should also be allowed to do other state related Ops that
>> release state, such as LOCKU and CLOSE (I'm not so sure about LOCK,OPEN,...).
>
>Server's are free to allow that. What if the client's don't? Or

If I understood the original question, it was "What can a client do to
get rid of locks when the ticket has expired, but the lease hasn't". The
above gives the client an alternative to doing a SetClientID, which throws
away all the locks. If the client doesn't, it doesn't.

>what if they do, but the scenario matches what Nico wrote:
>
>> User locks screen, [removes smartcard from reader,] goes on vacation,
>> creds expire, dirty data / locks cannot be flushed / unlocked.  Oops.
W.r.t. the dirty data. For dirty data,
I won't allow AUTH_SYS unless AUTH_SYS is always allowed for writing from
that machine ip#, but I might consider a valid host based AUTH_GSS cred. for
the same princ. as the one used for SetClientID for the client referenced by
the stateid to go ahead, assuming there is a current Open for writing
associated with the stateid. (I have to think about this one a little
more.)

> In this scenario, the application does not close or attempt to unlock
> the file. Whether smart-card enabled Kerberos or PKI is
> being used at all, makes no difference; the problem applies
> ifone is using AUTH_SYS.

If there is a lock conflict, I'd call this one "A sysadmin's nightmare"
and only manual intervention is going to solve the problem?

> The client chose to use a weak flavor to establish the client id
> and thus assumed the risk.
Yep, I see what you mean. (As a sysadmin in the trenches here, I can
say that a lot of "users" do need to be protected from themselves. In
some cases, the only control a sysadmin has is server access.)
In any case, the denial of service attack is still
a concern (which is why the principal restriction was put in SetClientID
in the first place, wasn't it?).

> Given that that NFSv4 uses LOOKUP for mounting,
> it means that following that approach,
> root can now browse anyones directories. I'm
> not sure that is desirable.

I suppose some clients would use Lookup. I was thinking PutRootFH,
PutPubFH and SecInfo to find out what authentication it needs to use.
(For my server, root level lookups would probably be allowed by anyone,
since it is just a pseudo-root for NFSv4 mounts.)
(I can see your argument that Lookup might not be a candidate, in general.)

Sounds like there be some interoperability Alligators in these here
swamps, rick

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

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Tue, 30 Sep 2003 11:47:10 -0400

> associated with the stateid. (I have to think about this one a little

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.

> in the first place, wasn't it?).

maybe i'm just ignorant, or UNIX centric: which applications that use 
byte-range locking are we worried about?

---

From: Trond Myklebust <[email-masked]>
Date: 30 Sep 2003 12:44:01 -0400

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Sep 2003 09:50:51 -0700

> down state on the user's behalf prior to the actual ticket expiration?

It can try, and it may fail (e.g., due to untimely network problems, too
much dirty data to write in too little time, etc...).

I think the long and the short of it is: credential expiration can lead
to data/state loss - oh well.

We can lessen the impact of this in various ways, but the problem cannot
be done away with altogether.  It's security vs. convenience all over
again.

> your credential without first notifying the NFS client.

That's an implementation issue, but, yes, that too.

Cheers,

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Sep 2003 15:45:07 -0400

>>>>> " " == Nicolas Williams <[email-masked]> writes:

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

     > That's an implementation issue, but, yes, that too.

No, it's not purely an implementation issue.

As the KDC administrator from Hell, I am quite free to decide to
revoke your credentials by removing the keytab entry. If your NFS
client then tries to re-establish a GSS context in order to flush out
pending data or tear down state... Oops...

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Sep 2003 13:27:48 -0700

> pending data or tear down state... Oops...

Well, yes, but I thought you were referring to someone destroying a
ticket cache on the client without giving the kernel a chance to clean
up first.

Nico
--