9:25 a.m.
Scenario:
Let's say that there are some nfs clients that negotiate rpcsec_gss security with
the nfs v4.1 server (Ganesha). The subsequent nfs-requests from those clients
work using rpcsec_gss based authentication. At a later point in time, the server's
state changes and it cannot accept rpcsec_gss security. By this I mean that
ntirpc is no longer able to authenticate rpcsec_gss requests. The export ACLs
may allow or disallow such requests using krb5* security, but since the
authentication happens before the export ACLs check is done, the requests will
anyways fail for mounted clients.
In such a scenario, what is the best way for server to tell the client to re-
negotiate the security flavor (say, downgrade to auth-sys) and perform further
requests using that?
So what happens is that the request is authenticated, possibly checked (krb5i) or
decrypted (krb5p) at the RPC layer. The RPC layer passes the authentication flavor and the
credentials (Kerberos principle) to Ganesha. Ganesha then turns the principle into
uid/gid.
Then Ganesha starts to process the request and at some point in the processing of an
NFSv4.x request. One of the first operations will be a PUTFH. From this, Ganesha
determines the applicable export. At that point the export permission check is performed.
If the export does not allow the authentication flavor, it will fail, and Ganesha will
respond to the client with NFS4ERR_WRONGSEC which will trigger the client to re-negotiate
security flavor. Two other paths are LOOKUP and READDIR that can result in crossing an
export boundary and gain trigger an NFS4ERR_WRONGSEC.
So if something changes the security flavors for an export, an NFS4ERR_WRONGSEC will be
sent to the client which will then respond by querying the allowed security flavors from
which it will pick one and create a new security context for future requests.
Frank