The security type that the client authenticated with plays a special role in export rules. You must understand how the security type determines the levels of access the client gets to a volume or qtree.
The three possible access levels are as follows:
Because the access level by security type is evaluated in this order, you must observe the following rules when constructing access level parameters in export rules:
|For a client to get access level...||These access parameters must match the client's security type...|
|Normal user read-only||Read-only (-rorule)|
|Normal user read-write||Read-only (-rorule) and read-write (-rwrule)|
|Superuser read-only||Read-only (-rorule) and -superuser|
|Superuser read-write||Read-only (-rorule) and read-write (-rwrule) and -superuser|
The following are valid security types for each of these three access parameters:
This security type is not valid for use with the -superuser parameter.
When matching a client's security type against each of the three access parameters, there are three possible outcomes:
|If the client's security type...||Then the client...|
|Matches one specified in the access parameter.||Gets access for that level with its own user ID.|
|Does not match one specified, but the access parameter includes the option none.||Gets access for that level but as the anonymous user with the user ID specified by the -anon parameter.|
|Does not match one specified and the access parameter does not include the option none.||Does not get any access for that level.
This does not apply to the -superuser parameter because it always includes none even when not specified.
The export policy contains an export rule with the following parameters:
Client #1 has the IP address 10.1.16.207, has user ID 0, sends an access request using the NFSv3 protocol, and authenticated with Kerberos v5.
Client #2 has the IP address 10.1.16.211, has user ID 0, sends an access request using the NFSv3 protocol, and authenticated with AUTH_SYS.
Client #3 has the IP address 10.1.16.234, has user ID 0, sends an access request using the NFSv3 protocol, and did not authenticate (AUTH_NONE).
The client access protocol and IP address matches for all three clients. The read-only parameter allows read-only access to all clients regardless of security type. The read-write parameter allows read-write access to clients with their own user ID that authenticated with AUTH_SYS or Kerberos v5. The superuser parameter allows superuser access to clients with user ID 0 that authenticated with Kerberos v5.
Therefore, client #1 gets superuser read-write access because it matches all three access parameters. Client #2 gets read-write access but not superuser access. Client #3 gets read-only access but not superuser access.