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

From: Mike Eisler <[email-masked]>
Date: Mon, 29 Sep 2003 16:40:08 -0700

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

So there are two issues here. One is whether to allow servers
to require certain security flavors for SETCLIENTID. That's
a reasonable idea, but can't be done till NFSv4.1 due to the
lack of WRONGSEC in the SETCLIENID* return codes.

Two is whether to allow the flavor used for SETCLIENTID to
also issue the LOCKU and CLOSE (DELEGRETURN?) if it has
the same principal as original locker, even if the flavor
differs from what was used to get the lock.

That I think is a reasonable and correct thing to allow.
Though I'm still puzzled as to what problem it solves.

	-mre

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