Several factors can affect why rights are not being evaluated and correctly applied. This procedure helps you debug why assigned rights might not be available to users, roles, or processes. Several of the steps are based on Order of Search for Assigned Rights.
Before You Begin
You must assume the root role. For more information, see Using Your Assigned Administrative Rights.
# svccfg -s name-service/switch svc:/system/name-service/switch> listprop config config application config/value_authorization astring solaris.smf.value.name-service.switch config/default astring files ldap config/host astring "files dns mdns ldap" config/netgroup astring ldap config/printer astring "user files"
In this output, all services that are not explicitly mentioned inherit the value of the default, files ldap. Therefore, passwd and its related attribute databases, user_attr, auth_attr, and prof_attr, are searched first in files, then in LDAP.
The nscd daemon can have a lengthy time-to-live interval. By restarting the daemon, you update the naming service with current data.
# svcadm restart name-service/cache
Run the command once for every attribute. For example, the following commands indicate which rights are assigned and where the assignment was made for the user jdoe. The lack of output indicates that jdoe is using the defaults.
$ userattr -v access_times jdoe $ userattr -v access_tz jdoe $ userattr -v annotation jdoe $ userattr -v auth_profiles jdoe $ userattr -v defaultpriv jdoe $ userattr -v limitpriv jdoe $ userattr -v idlecmd jdoe $ userattr -v idletime jdoe $ userattr -v lock_after_retries jdoe $ userattr -v pam_policy jdoe $ userattr -v unlock_after jdoe $ userattr -v auths jdoe Output indicates authorizations from rights profiles Basic Solaris User :solaris.mail.mailq,solaris.network.autoconf.read, solaris.admin.wusb.read Console User :solaris.system.shutdown,solaris.device.cdrw, solaris.device.mount.removable,solaris.smf.manage.vbiosd,solaris.smf.value.vbiosd $ userattr -v audit_flags jdoe user_attr: fw:no Output indicates jdoe is individually assigned audit flags $ userattr -v profiles jdoe user_attr: Audit Review,Stop Output indicates two assigned rights profiles $ userattr roles jdoe user_attr : cryptomgt,infosec Output indicates two assigned roles
The output indicates that jdoe is directly assigned audit flags, two rights profiles, and two roles. The assigned authorizations are from default rights profiles, set either in the account-policy SMF stencil or in files in the /etc directory. To determine the source of the default rights profiles on your system, see New Feature – Enabling the account-policy Service.
Because jdoe is directly assigned audit flags, no audit flag values in the rights profiles will be used.
The rights profiles are evaluated in order, first the Audit Review rights profile, then the Stop profile.
All other rights are assigned to jdoe in the roles cryptomgt and infosec. To view those rights, jdoe must assume each role, then list the rights.
If the right is not directly assigned to the user, continue with the following checks.
The source of an authorization assignment is not important because authorizations accumulate for users. However, a misspelled authorization fails silently.
For example, some commands require uid=0 rather than euid=0 to succeed. Review the man page for the command to determine whether the command or any of its options require authorizations.
The value of the attribute in the earliest rights profile in the list is the value in the kernel. If this value is incorrect, either change the value in that rights profile, or reassign the profiles in the correct order. See How to Reorder Assigned Rights.
Follow the same checks as you performed for authenticated rights profiles.
If the right is assigned to a role, the user must assume the role to obtain the rights.
If the profile exists, use it. Assign it to the user as an authenticated rights profile or a regular rights profile. Order the profile before any other rights profile that includes the command that requires this authorization to succeed.
Assign the privilege to the command that requires it, add the required authorizations, place the command and authorizations in a rights profile, and assign the profile to the user.
Administrative commands must be executed in a profile shell. Example 76, Determining Whether You Are Using a Profile Shell shows how to test for a profile shell.
To reduce the likelihood of user error, you can try the following:
Assign a profile shell as the user's login shell.
Instruct users to precede all privileged commands with the pfexec command.
Remind the user to run administrative commands in a profile shell.
If your site is using roles, remind the user to assume the role before running administrative commands. For an example of successful command execution as a role rather than as a user, see Example 78, Running the Privileged Commands in Your Role.
When a privileged command does not work, the user tests for the PRIV_PFEXEC flag, then runs the command. The error message might not indicate that the problem is a privilege problem.
$ praudit 20120814200247.20120912213421.example-system praudit: Cannot associate stdin with 20120814200247.20120912213421.example-system: Permission denied $ ppriv $$ 107219: bash flags = <none> ... $ pfbash $ ppriv $$ 1072232: bash flags = PRIV_PFEXEC ... $ praudit 20120814200247.20120912213421.example-system /** Command succeeds **/Example 77 Determining the Privileged Commands of a Role
In this example, a user assumes an assigned role and lists the rights that are included in one of the rights profiles. The rights are truncated to emphasize the commands.
$ roles devadmin $ su - devadmin Password: xxxxxxxx $ profiles -l Device Security ... profiles=Service Configuration /usr/sbin/add_drv uid=0 /usr/sbin/devfsadm uid=0 privs=sys_devices,sys_config, sys_resource,file_owner, file_chown,file_chown_self, file_dac_read /usr/sbin/eeprom uid=0 /usr/bin/kbd /usr/sbin/list_devices euid=0 /usr/sbin/rem_drv uid=0 /usr/sbin/strace euid=0 /usr/sbin/update_drv uid=0 /usr/sbin/add_allocatable euid=0 /usr/sbin/remove_allocatable euid=0 Service Configuration /usr/sbin/svcadm /usr/sbin/svccfgExample 78 Running the Privileged Commands in Your Role
In the following example, the admin role can change the permissions on the useful.script file.
$ whoami jdoe $ ls -l useful.script -rwxr-xr-- 1 elsee eng 262 Apr 2 10:52 useful.script $ chgrp admin useful.script chgrp: useful.script: Not owner $ su - admin Password: xxxxxxxx $ chgrp admin useful.script $ chown admin useful.script $ ls -l useful.script -rwxr-xr-- 1 admin admin 262 Apr 2 10:53 useful.script