Skip to main content

How security types determine client access levels

Contributors netapp-aherbin
PDFs

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:

  • any

  • none

  • never

    This security type is not valid for use with the -superuser parameter.

  • krb5

  • krb5i

  • krb5p

  • ntlm

  • sys

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 the one specified in the access parameter.

Gets access for that level with its own user ID.

Does not match the 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 the 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:

  • -protocol nfs3

  • -clientmatch 10.1.16.0/255.255.255.0

  • -rorule any

  • -rwrule sys,krb5

  • -superuser krb5

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 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.