Table of ContentsView in Frames

How security types determine client access levels

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:

  1. Read-only
  2. Read-write
  3. Superuser (for clients with user ID 0)

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:

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.

Example

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.