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