Checking custom permissions when no policy is used

Although shipped systems should always use a security policy, the code still needs to account for what happens with permission checking when no policy is used. In most cases, checks for custom permissions are additional checks—they are made in addition to the usual read/write checks a resource manager performs on a request. The system assumes that additional checks protect operations that require additional permissions. When no security policy is in use, the only option available to secpol_check_permission() is to require that the caller is root (i.e., has an effective user ID of 0).

You can change this built-in behavior by passing the SECPOL_PERM_STRICT flag to secpol_get_permission(), which causes the function to fail when no policy is in use or the policy does not contain the required class or permissions. The secpol_get_permission() function returns NULL with an errno of ENOTSUP when a policy is not in use, which the resource manager can respond to as appropriate. In most cases, any other error should be considered fatal because if the same code is used with a security policy in use, it is inappropriate to bypass the permission checks because of a system configuration error.