Using ZFS ACLs to restrict what a user can do
By martin on Aug 31, 2007
On some systems where we are really paranoid,
we restrict who can execute most
just in case of a zero day exploit.
I.e. we only let the administrators can run those commands.
Previously if you wanted to create this kind of restriction,
you had to first
chmod 4750 the files,
and then grant all but the user(s) you wanted to restrict to a group and
This was very messy, and you could not have two different sets of restrictions.
Note: if you change file owner, group or permissions for files in a package,
you must use
installf to update the software installation database.
# chmod 4750 /usr/bin/su # chgrp sysadmin /usr/bin/su # installf SUNWcsu /usr/bin/su 4750 root sysadmin
Then came UFS ACLs. It allowed you to add multiple ACLs to the same file,
so now you could have multiple sets of files with execute restrictions,
but you still had to
chmod 4750 all involved files.
Now that we have ZFS it is possible to use the ZFS ACLs to revoke permissions,
so if the user
danny should not be able to execute
/usr/bin/su you can just
add an ACL to remove the execute permission for that user.
# chmod A+user:danny:execute:deny /usr/bin/su
danny tries to execute
su it'll look like this:
$ ls -l /usr/bin/su -r-sr-xr-x+ 1 root sys 34624 Feb 26 2007 /usr/bin/su $ su - bash: su: Permission denied
As with UFS ACLs the way to spot that a file has an ACL is the + sign at the end of
the permissions when you execute
If you want to see the full ACL use this
$ ls -v /usr/bin/su -r-sr-xr-x+ 1 root sys 34624 Feb 26 2007 /usr/bin/su 0:user:danny:execute:deny 1:owner@:write_data/append_data:deny 2:owner@:read_data/write_xattr/execute/write_attributes/write_acl /write_owner:allow 3:group@:write_data/append_data:deny 4:group@:read_data/execute:allow 5:everyone@:write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:deny 6:everyone@:read_data/read_xattr/execute/read_attributes/read_acl /synchronize:allow