It's the per-file authorized edit of administrative text files.
Great, great tool! And it's even audit enabled!
Imagine the cumbersome work to approach (not match) it with sudo!
For the auditing I think it's worthy to quote the man page:
..., in the case of a successful update, an
attempt to make unauthorized use, or if an error occurs, an
audit record is generated to capture the subject, the file
name, the authorization used, the file change if any, and
the success or failure of the operation. The audit event
type and default class is one of:
AUE_admin_edit:edit administrative file:as
AUE_admin_file_create:create administrative file:as
AUE_admin_file_remove:remove administrative file:as
The fundamental idea is rather straightforward.
Add the proper Solaris authorization related to the administrative file.
Example:
Let's authorize user1 to edit /etc/hosts.
The following is just for quick learning, don't do it exactly this way.
In fact, the proper way of doing it is to create a RBAC profile or a role.
# usermod -A +solaris.admin.edit/etc/hosts user1
UX: usermod: user1 is currently logged in,
some changes may not take effect until next login.
# getent user_attr user1
user1::::auths=solaris.admin.edit/etc/hosts;...
In the above example, user1 happened to be logged in.
But that won't be an issue for this particular case.
Otherwise, it's necessary to get a new session.
user1$ pfedit /etc/hosts
...
#
::1 localhost
127.0.0.1 localhost loghost
#
...
~
~
"/tmp/hosts.pfedit.AXaGmg" 25L, 587C
Hadn't been for the given Solaris authorization user1 would get:
user1$ pfedit /etc/hosts
pfedit: User user1 is not authorized...
Or at best (typically after a w!):
user1$ vi /etc/hosts
...
"/etc/hosts"
"/etc/hosts" E212: Can't open file for writing
Press ENTER or type command to continue
The pfedit command can also be used to create administrative text files.
Those files can also be deleted (removed) with the -r option.
It isn't a good practice to apply the authorization on a per-user basis.
Let's see a more realistic approach.
In general, it's recommended to:
- Gather related authorizations in a profile.
- Assign the profile to a role and the role to authorized logins (users).
For instance:
Assume that user1 and role1 already exist, of course.
Let's invent a level 0 type 1 administration profile.
# profiles -p "Admin L0 T1"
profiles: Admin L0 T1> set auths=solaris.admin.edit/etc/hosts
profiles: Admin L0 T1> set desc="Level 0 Type 1 Administrator"
profiles: Admin L0 T1> exit
# rolemod -P +"Admin L0 T1" role1
# usermod -R +role1 user1
But as in the man page it may be OK (or enough) to not require a role.
Simply assign the profile directly to the login.
# usermod -P +"Admin L0 T1" user1
The trade-offs should be clear:
Directly assigning profiles to logins complicates account management, whereas assigning profiles to roles requires inputing a password every time roles are used (but still better than having a sudo password timeout or a sudo su -).
