Access Control Lists

Team-Fly    

Solaris™ Operating Environment Boot Camp
By David Rhodes, Dominic Butler
Table of Contents
Chapter 4.  Permissions and All That


Most of the time you should be able to achieve the file security you require using a combination of the standard Solaris permissions and Solaris groups. However, if you cannot easily achieve the desired result you can also make use of Access Control Lists (ACLs).

ACLs allow you to go beyond being able to set permissions for a file's owner, group, and others, and let you add specific permissions for specific users. They also allow the owner of the file to manage the ACL for that file so they do not have to rely on the system administrator for certain tasks (such as making changes to the /etc/group file).

To make use of ACLs, you need to become familiar with two Solaris commands. These are getfacl, which will display a file's ACL; and setfacl, which will set a file's ACL. Even if you have not set any ACLs on a file, getfacl will still produce some output based on the existing standard permissions.

 hydrogen# ls -l test_file -rw-r-----   1 root     other       0 Aug 13 16:39 test_file hydrogen# getfacl test_file # file: test_file # owner: root # group: other user::rw- group::r--              #effective:r-- mask:r-- other:--- hydrogen# 

From the ls -l output above we can see that the file is owned by root and belongs to the group other. The owner can read and write to the file, members of the group other can only read the file, and everybody else cannot do anything at all to the file.

The output from the getfacl command shows us the same information, but as an ACL. We can see who the owner and group are, and we can see that the owner (user) can read and write to the file, the group can read the file, and others cannot access the file at all. The file has a mask, which is set to "r--" and means "read only."

This specifies the maximum permissions that anybody who is not the owner can have, regardless of what that person's individual permission is set to. This is why the group entry also has an effective permissions entry next to it. Even though getfacl has returned the above information, there is actually no ACL for the file. The information presented is just inferred from the standard permissions. A file will not have an ACL unless one is set using the setfacl command.

As we have just seen, the above file (test_file) can be written to and read from by the owner and can only be read by members of its group. What if we had one more user that also needed to be able to write to the file? It would be no good putting that user in the group other, because then the user would only have read permission. If we were to create a new group with read and write permission and put the file and the user in that group, everybody in the group other would suddenly no longer be able to access the file. The only way we could achieve this specific requirement is by the use of ACLs. We can simply set an ACL for the new user, who will then be able to do what he or she needs to without any impact on anyone else.

The following example shows how the user jgreen can be given read and write permissions to the file test_file:

 hydrogen# ls -l test_file -rw-r-----   1 root     other       0 Aug 13 16:39 test_file hydrogen# setfacl -m user:jgreen:rw- test_file hydrogen# ls -l test_file -rw-r-----+  1 root     other       0 Aug 13 17:05 test_file hydrogen# getfacl test_file # file: test_file # owner: root # group: other user::rw- user:jgreen:rw-         #effective:r-- group::r--              #effective:r-- mask:r-- other:--- hydrogen# 

The setfacl command above says that we want to modify the ACL for the file test_file to enable the user jgreen to have read and write access. Because we have used the setfacl command, the file does have an ACL now, and we can see this by the character "+" shown after the standard permissions on the output from ls -l.

We can see the effect of the command in the new output from getfacl. There is now an entry for the user jgreen stating that he has read and write permission. However, even though we have specifically said we want jgreen to have read and write access, he will only be able to read the file because the mask is set to "r--" (or read only).

We can issue a new setfacl command to change the mask and so let jgreen have the access we originally intended:

 hydrogen# setfacl -m mask:rw- test_file hydrogen# getfacl test_file # file: test_file # owner: root # group: other user::rw- user:jgreen:rw-         #effective:rw- group::r--              #effective:r-- mask:rw- other:--- hydrogen# 

Because the ACL mask is now set to "rw-," the effective permissions for jgreen can become the same as the value set. The ACL mask provides a way of temporarily restricting the permissions on a file without having to first note down what each of the ACL entries was. The mask can later be opened, and everyone will get the permissions they were originally allocated. The mask has only worked in this way since Solaris 7; prior to that, the mask was always the same as the file's group permission, so if the group permission was changed using chmod, it would also change to mask of the ACL.

ACL entries can be added to or changed using setfacl with the "-m" flag, as we have seen, but we can also use a "-s" flag, which will cause any existing ACL to be replaced by the one specified. The following example will set the owner's permissions to read and write, the group's permissions to read only, other's permissions to nothing, and the ACL mask to read and write. It also sets up ACL entries for the users jgreen (who gets read and write permission) and msmsith (who just gets read permission). Any previous ACLs for that file would be removed.

[View full width]

setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:jgreen:rw-,user:msmith:r-- graphics/ccc.gifnew_file

Setting ACLs in this manner can become cumbersome, so it is also possible to set ACLs using a file containing the required ACL. The file should be in the same format as the output from getfacl. One way of speeding up the process of creating a large ACL is to store the output from a getfacl command into a file, edit the file so it reflects the actual ACL you require, and then use setfacl with the "-f" option:

 hydrogen# getfacl test_file >/tmp/acl_file <edit /tmp/acl_file> hydrogen# setfacl -f /tmp/acl_file another_file hydrogen# 

When you edit the file containing the output from getfacl you do not need to bother about the effective permissions because the hash character (#) is treated as a comment by setfacl.

There is also a useful shortcut to give a file the same ACL as another:

 hydrogen# touch test_file2 -rw-r-----+  1 root     other       0 Aug 13 17:05 test_file -rw-r--r--   1 root     other       0 Aug 14 12:42 test_file2 hydrogen# getfacl test_file | setfacl -f - test_file2 hydrogen# ls -l test_file* -rw-r-----+  1 root     other       0 Aug 13 17:05 test_file -rw-r-----+  1 root     other       0 Aug 14 12:42 test_file2 hydrogen# getfacl test_file2 # file: test_file2 # owner: root # group: other user::rw- user:jgreen:rw-         #effective:rw- group::r--              #effective:r-- mask:rw- other:--- hydrogen# 

The minus sign following the "-f" tells setfacl that the file containing the ACL is actually its own standard input. You will see that, as well as setting the ACL of test_file2 to be the same as test_file, the standard permissions have also changed.

ACLs will stay attached to a file even if it is copied or renamed, but they can be completely removed from a file using setfacl with the "-d" flag. Unfortunately, you have to remove each member of the ACL by name, but at least you only have to specify the named users and groups (i.e., not the owner, group, other, or mask). When the last member is removed, the ACL will be cleared and the plus sign will no longer appear in the output from the ls -l command. To completely remove the ACL for test_file2, we would only need to remove the entry for the user jgreen:

 hydrogen# setfacl -d user:jgreen test_file2 hydrogen# ls -l test_file2 -rw-r-----   1 root     other       0 Aug 14 12:42 test_file2 hydrogen# 

If you have tried any of the above examples and found that you were getting errors similar to the one below, now is the time to put you out of your misery.

[View full width]

hydrogen# touch test_file hydrogen# ls -l test_file -rw-r--r-- 1 root other 0 Aug 15 15:38 test_file hydrogen# setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:jgreen:rw-,user:msmith: graphics/ccc.gifr-- test_file test_file: failed to set acl entries setacl error: Operation not applicable hydrogen#

ACLs can only be used on certain types of filesystems, so if you received the above error it means you probably tried to set ACLs on a filesystem whose type does not support them. Chances are you tried the command out on a file in /tmp (whose type, TMPFS, does not support ACLs). This also means that if you copy or move a file into /tmp for any reason its ACL will be lost. ACLs can be used on UFS filesystems and over NFS, provided both client and server are running at least Solaris 2.5.

You should also note that if you use chmod to change the group permissions of a file with ACLs set, you might inadvertently also change the group ACL permission and the ACL mask. Therefore, it is best to either use setfacl to change the permissions or to ensure that you check the ACL first using getfacl.

ACLs can be set on directories as well as files. They are set in exactly the same way we have seen, but in addition directories can be given default ACLs. The default ACL setting for a directory will be used for any files or directories that are created under it. The following command will set an ACL for a directory (unfortunately, setting ACLs for directories involves a fairly long command):

 hydrogen# ls -ld dir drwxr-x---   2 jgreen   staff        512 Aug 15 16:47 dir hydrogen# setfacl -s user::rwx,group::r-x,other:    ---,mask:rwx,default:user::r-x,default:group::    r-x,default:other:---,default mask:rwx dir hydrogen# ls -ld dir drwxr-x---+  2 jgreen   staff        512 Aug 15 16:47 dir hydrogen# getfacl dir # file: dir # owner: jgreen # group: staff user::rwx group::r-x              #effective:r-x mask:r-x other:--- default:user::r-x default:group::r-x default:mask:rwx default:other:--- hydrogen# 

This means that when a directory is created under the directory dir, it will automatically get an ACL equal to the default values set within dir. Although files created under dir will not get an ACL set specifically, the default ACL of the directory will determine the permissions of the files rather than the umask.

 hydrogen# umask 0022 hydrogen# touch new_file hydrogen# ls -l new_file -rw-r--r--   1 root     other       0 Aug 15 17:14 new_file hydrogen# cd dir hydrogen# touch new_file2 hydrogen# ls -l new_file2 -r--r-----   1 root     other       0 Aug 15 17:17 new_file2 hydrogen# mkdir new_dir hydrogen# ls -ld new_dir dr-xr-x---+  2 root     other     512 Aug 15 17:22 new_dir hydrogen# getfacl new_dir # file: new_dir # owner: root # group: other user::r-x group::r-x              #effective:r-x mask:rwx other:--- default:user::r-x default:group::r-x default:mask:rwx default:other:--- hydrogen# 

You will see above that the directory created under dir does not receive the same permissions as dir, but permissions based on the default ACLs of dir. It is also possible to add default ACLs for specific users and groups to directory ACLs:

 hydrogen# setfacl -m default:user:msmith:rwx dir hydrogen# getfacl dir # file: dir # owner: jgreen # group: staff user::rwx group::r-x              #effective:r-x mask:r-x other:--- default:user::r-x default:user:msmith:rwx default:group::r-x default:mask:rwx default:other:--- hydrogen# 

This will now cause all files and directories created under dir to have an ACL that also includes the above entry for user msmith:

 hydrogen# cd dir hydrogen# touch new_file3 hydrogen# getfacl new_file3 # file: new_file3 # owner: root # group: other user::r-- user:msmith:rwx         #effective:rw- group::r--              #effective:r-- mask:rw- other:--- hydrogen# 

One of the downsides of ACLs is that they are not easy to find, as there is no specific option to tell the find command to report them. The only real way is to examine the output from ls -l, which is not that practical and you cannot actually see what the ACL permissions are without using the getfacl command. This means that ACLs are a good way for hackers to add backdoors to your system without an easy way of finding them.

If a file has an ACL set, it will not be stored in the file's inode; instead, it is stored in a shadow inode. This means that if you use a large number of ACLs, you could find the filesystem running short of inodes.


    Team-Fly    
    Top
     



    Solaris Operating Environment Boot Camp
    Solaris Operating Environment Boot Camp
    ISBN: 0130342874
    EAN: 2147483647
    Year: 2002
    Pages: 301

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net