Role transitions specify which special roles a given role is allowed to authenticate to. This applies to special roles that do not require password authentication as well. If a user tries to authenticate to a role that is not within his transition table, he will receive a permission denied error. A common mistake when creating a new special role is forgetting to create a role_transitions rule for the role that will transition to the special role, which a user confuses with having entered an incorrect password. The role_transitions rule is added below the declaration of a role, but before any subject declaration.
role_transitions <special role 1> <special role 2> ... <special role n>
role person u role_transitions www_admin dns_admin subject / ...
This rule restricts the use of a role to a list of IPs. If a user is on the system who would normally get the rule does not belong to the specified list of IPs, the system falls back through its method of determining a role for the user (checking for an applicable group role then falling back to the default role). This rule can be specified multiple times for a role. Like role_transitions, it should be added below the declaration of a role, but before any subject declaration.
role_allow_ip <IP>/<optional netmask>
role person u role_allow_ip 192.168.1.0/24 subject / ...
A netmask of 0.0.0.0/32 permits use of the role only by local processes that haven't been used by remote clients .
This rule ensures that a user cannot accidentally create a file that others can read (a confidentiality issue). Like previous role attributes, it should be added below the declaration of a role, but before any subject declaration.
role person u role_umask 077 subject / ...