> Can we make this sysctl'abe, or mark it with a large XXX XXX?  Consing
> up AUTH_UNIX credentials is going to break horribly with RPSEC_GSS
> (RFC 2623, RFC 2203) which ISTR various people are working on....

Yep, I agree this stuff should only be done for AUTH_UNIX. My newer server
code has AUTH_GSS working in it. I am just coding the callback part (which
does Initiator cred, so should be usable for a client as well). I use a
flag called ND_GSS to indicate the cred were acquired via GSS. Whatever
you do, I think you probably want some sort of flag indicating if the cred were
acquired via AUTH_GSS or AUTH_UNIX, so you can do the above based on that.

> The file owner. Otherwise you can still do a chown, making writes fail
> when they should be succeeding according to Unix semantics.

Here's my take on this (worth what you payed for it):
For the server:
- If a server is willing to give a client access via AUTH_UNIX with
  root->nobody, then the only security the server can apply is for
  files owned by root. (The client can say it is any uid it wants to,
  which means security has been trusted to the client for files not
  owned by root.)
  - As such, from a security point of view, there really isn't any point
    in checking anything for files not owned by root.
  But...
  - There are "dumb, honest, trustworthy" clients out there. For example,
    a client running under PC-DOS. These guys send an appropriate uid
    and expect the server to handle access checking for them.
  As such, I believe the server side should apply access checking for
  these "dumb, honest, trustworthy clients", but with the understanding
  that it does not "enhance security". One possible exception here might
  be to not check the user-mode bits if the cred uid == file_owner. (If
  a server chooses to do this, I think it should be optional, possibly
  based on an export flag?)

  For AUTH_GSS, I believe the server should use the credentials that
  the authenticator mapped to on the server, since "trust" is user-based
  instead of host-based. The only exception might be I/O Ops on V4, where
  the stateid refers to a valid Open or Open_delegation. For this case, I
  would argue that the authenticator used for the Open can be considered
  sufficient, even if it no longer is allowed access via owner/mode on
  the file, although this could definitely be open to debate:-)

For the Client:
- For AUTH_SYS, if it has done all the checking it would apply to local
  files at open(), it might as well use whatever has the best chance of
  success. This seems to me to be the uid/gid that is the current ownership
  of the file. (Since cached attributes could be out of date, it should
  probably: "zap the attribute cache, do a Getattr RPC/Op and then use
  that uid/gid for a retry, when NFSERR_ACCES comes back from an I/O
  RPC/Op"?)

- For AUTH_GSS, I think it should probably use the authenticator for the
  current client uid. (I could see an argument for using the authenticator
  used for Open for V4, but since this isn't specified in the RFC, I think
  it is, at best, a fallback, if the client uid authenticator gets
  NFSERR_ACCES. I am an old-fashioned guy, so I still spell access with one
  S:-)

Sound about right? rick