Subject: Re: [nfsv4] NFS4ERR_CLID_INUSE when SetClientID changes authenticationmechanisms

From: Jim Rees <[email-masked]>
Date: Tue, 14 Dec 2004 14:54:42 -0500

Well... AUTH_SYS is fine if your security is guaranteed by other means
  (no exterior IP connection, no physical access by unauthorized
  personnel, ...).
  
  Things like allowing stateful access to world + dog (even if it is
  "only" a read-only partition), however, is a no-no...

I think it would be a shame if NFSv4 can't provide read-only access to the
world using auth_sys without exposing itself to attacks.  Anonymous,
unauthenticated read-only access accounts for the most file system traffic
on the Internet, by far.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 14 Dec 2004 15:23:40 -0500

> unauthenticated read-only access accounts for the most file system traffic

You can provide that sort of access without requiring the need for
setclientid--the special stateid's should be sufficient.

How well do current clients deal with servers that won't allow
setclientid?  Do any current server allow you to forbid a set of clients
from doing setclientid?

Also, does authentication actually solve the problem?  Authenticated
clients can also grab each other's client identifiers.  I suppose it
does make it easier for you to revoke access from ill-behaved clients if
you can identify the problem.

But the set of authenticated clients could be quite large.  You're
probably going to be giving out an awful lot of credentials if you want
to provide access to everyone in your organization, and make it possible
for all their machines to boot unattended.

It would be nice if setclientid were a more innocent operation.

--b.