Using Access Control Lists

The basic UNIX permission structure enables administrators to assign Read, Write, and/or Execute permissions to three classes of users: the owner (user), group, and everyone else (other). In many cases, these permissions will be sufficient to manage Solaris.

However, what happens when a user other than the owner needs to access the file? There are several ways, using standard permissions, that you could accomplish this. One would be to change the owner of the file to the new user. But then what about the previous owner's access? A second way would be to put the user in the group that owns the file and to make sure that the group has proper access. But then other users who might be part of the group have access, which might be undesirable. A third way would be to create a group specifically for the user, make the new group the owner, and give the new group permissions. This can cause a lot of problems, the least of which is an excessive number of groups. Finally, you could grant permissions to everyone (other), but this could cause a serious security problem. None of these solutions seems very good, so what can you do?

Access Control Lists (ACLs) enable you to not only assign permissions via the traditional security structure, but to define permissions for additional specific users and groups. Using the previous example, all you would need to do is set up an ACL and give the user's account proper permissions to the file. The problem is solved.

Understanding ACL Entries

To understand the syntax used in creating and managing ACLs, it helps to know what the structure of an access control entry looks like for both files and directories. When ACLs are created on a file, each entry will have the following fields:

 entry_type:UID(orGID):permissions 

One file can have several entries. For example, you can define the owner's permissions, as well as permissions for several groups and individual users. Each ACL entry will have its own line. Table 13.1 lists the different ACL entry types for files.

Table 13.1: File-Based ACL Entries

Entry

Description

user::permissions

Permissions for the file's owner.

group::permissions

Permissions for the file's group owner.

other:permissions

Permissions for the other group.

mask:permissions

Defines the ACL mask. This entry defines the maximum allowable permissions for users (other than the owner) and groups. For example, if you were to set mask::r--, users (other than the owner) and groups could have no more than Read access.

user:UID:permissions

Permissions for a specific user. You can specify a username or UID in the UID field.

group:GID:permissions

Permissions for a specific group. You can specify a group name or GID in the GID field.

So when looking at an ACL for a file, you might see an entry such as user::rwx, which would mean that the owner has Read, Write, and Execute permissions. Another possible entry would be group:1850:r--, meaning that users in the group with GID 1850 have Read access to the file.

Note 

When creating access control entries, you can abbreviate user with u, group with g, other with o, and mask with m.

Tip 

A quick way to change permissions for all users is to modify the mask. Changing the mask value to mask:--- will disable access for all users except for the file's owner.

Access Control Lists can also be set on directories. If you have a large number of files that you want to enable ACLs on, then putting them into a directory might ease your file management burden. If you create a file or directory in a directory that has an ACL, the new file or directory will have the same permission structure as its parent directory.

When you create an ACL on a directory for the first time, you must specify default permissions for the directory's user owner, group owner, and other, and a mask, in addition to any permissions you want to assign to specific users or groups.

ACLs created on directories have the same entries as ACLs created on files, except that directories also have default entries with the following fields:

 default:entry_type:UID(orGID):permissions 

As you can see, the only difference between file and directory ACLs is the inclusion of the default entries for directories. The default field can be abbreviated with d, which makes it easy to remember that it's for directories only. (The entries are called default because any new files or directories will have those permissions automatically.) Otherwise, the fields for directories are identical to the fields for files, as shown in Table 13.1.

Managing ACLs

Now that you know what an ACL entry looks like, it's time to learn about creating them. ACLs are managed by two commands. The setfacl command is used to set, modify, and delete access control entries, and the getfacl command is for viewing current ACL entries.

Note 

For a review of access permissions, see Chapter 5.

Creating ACLs on Files

Setting up and modifying ACLs is done with the setfacl (set file access control list) command. Here is the syntax for setfacl:

 # setfacl -s entry_type::permissions,acl_entries filename 

For example, imagine that you are setting an ACL on a file named doc1. The owner needs full permissions, the group needs read, and a user named ldocter needs read access as well. When setting ACLs for the first time on a file, it's recommended that you specify permissions for all three standard classes (owner, group, other), as well as the mask. Here's the syntax you could use:

 # setfacl -s user::rwx,group::r--,other:---,mask:r--,user:ldocter:r-- doc1 

As noted earlier, you can also use first-letter abbreviations for user, group, other, and mask. In this example, if you had used user:ldocter:rwx, what permissions would ldocter have? The answer is Read-only. At first you might wonder why, but remember that the mask value determines the maximum permissions that users (other than the owner) and groups can have to the file. Because the mask is set to r--, all ldocter would have is Read access.

Note 

You can use either absolute or symbolic mode to set permissions when using setfacl.

The setfacl command has five arguments, which are shown in Table 13.2.

Table 13.2: setfacl Arguments

Argument

Description

-d acl_entry

Deletes the specified ACL entry. Note that deleting an entry doesn't necessarily guarantee that access to the file has been removed.

-f file

Sets the ACL for a new file based on the ACL for an existing file. Useful for copying ACLs between files.

-m acl_entry

Modifies an existing ACL entry.

-r

Recalculates the mask value. The permissions in the ACL mask are ignored and replaced by the maximum permissions necessary to allow access to all additional user, group, and other entries in the ACL. The permissions on additional users, groups, and other are not directly modified.

-s acl_entry

Sets a new ACL entry. Deletes any existing entries and replaces them with the specified acl_entry.

After you have created your ACL, you can check to ensure that your changes have taken effect. The first thing you can do is use the ls -l command to provide a directory listing. All files with ACLs have a + after the permissions. For example, in this directory listing, the doc1 file has an ACL, whereas doc2 does not:

 # ls -l -rwxr-----+   1 qdocter    author         554 Nov 29 13:46 doc1 -rwxr--r--    1 qdocter    author         554 Nov 29 13:47 doc2 

To see your Access Control List, use the getfacl (get file access control list) command. Here's an example showing the results of the setfacl command used earlier:

 # getfacl doc1 # file: doc1 # owner: qdocter # group: author user::rwx user:ldocter:r--      #effective:r-- group::r--           #effective:r-- mask:r-- other:--- 

In the previous directory listing, the doc2 file did not have an ACL. If you wanted to give doc2 an ACL identical to the ACL for doc1, you could use the setfacl -s command to create a new ACL. However, this is far too much work. An easier solution is to use getfacl and setfacl together to copy the ACL from doc1 to doc2. Here's how you would do it:

 # getfacl doc1 | setfacl -f - doc2 

This command takes the output of getfacl for doc1 and pipes it to the setfacl command for doc2. It's quick and it's easy.

Creating ACLs on Directories

Creating ACLs on directories is very similar to creating ACLs on files. The only major difference is that directories have default permissions. When you create an ACL on a directory for the first time, you must specify defaults for the directory owner, group, other, and mask. These defaults are in addition to the normal permissions you must create for the owner, group, other, and mask.

The list of setfacl entries can get quite cumbersome. Here's an example of setting an ACL on a directory named dir1:

 # setfacl -s d:u::7,d:g::4,d:o:0,d:m:6,u::4,g::4,o:0,m:6,u:501:7,u:502:6 dir1 # ls -l total 2 dr--r-----+  2 qdocter  author       512 Nov 30 11:25 dir1 -rwxr-----+  1 qdocter  author        80 Nov 29 13:46 doc1 -rwxr-----+  1 qdocter  author        80 Nov 29 14:04 doc2 -rw-r--r--   1 qdocter  author        80 Nov 29 14:05 doc3 # getfacl dir1 # file: dir1 # owner: qdocter # group: author user::r-- user:501:rwx        #effective:rw- user:502:rw-        #effective:rw- group::r--          #effective:r-- mask:rw- other:--- default:user::rwx default:group::r-- default:mask:rw- default:other:--- 

Because of the sheer length of the setfacl command, absolute mode was used instead of symbolic mode to shorten things up. As you can see in the getfacl output, the permissions are set, as are the defaults. The getfacl -d command shows only the default settings for directories:

 # getfacl -d dir1 # file: dir1 # owner: qdocter # group: author default:user::rwx default:group::r-- default:mask:rw- default:other:--- 

Now that the dir1 directory has an ACL, any new files created within dir1 will have their permissions defined by the default settings. New subdirectories in dir1 will have an ACL identical to dir1.

After you have created an ACL on a directory, you can use getfacl and setfacl to copy the ACL to another directory, just as you would for ACLs on files. You cannot, however, copy ACLs between files and directories.

Modifying ACLs

If you want to add an entry to an existing ACL, do so with the setfacl -m command. For example, to give the adocter user Read and Write access to doc1, you could use:

 # setfacl -m u:adocter:rw- doc1 

However, because of the restrictive mask, adocter would still have only Read access. To remedy this, change the mask with:

 # setfacl -m m:rw- doc1 

or

 # setfacl -r doc1 

To ensure that your changes have taken effect, use the getfacl command.

Removing ACLs

Entries are deleted from ACLs with the setfacl -d command. For example, to remove the adocter user from the ACL, you could use:

 # setfacl -d u:adocter doc1 

Once again, to ensure that your changes have taken effect, use getfacl.

Other ACL Information

You might wonder about potential conflicts between already-configured standard permissions and new permissions established in Access Control Lists. Is there a conflict? Does one override the other?

When you create an ACL, the permissions you set for the owner, group, and other will change the existing permissions (if applicable) set on the file or directory. Subsequently, when you modify permissions within the ACL, the standard permissions are modified as well. So when you use ls -l (and the file has an ACL), the permissions you see for user, group, and other are the same as defined in the ACL. The only way to see permissions for additional users and groups is to use getfacl.

Along the same lines, if you are using ACLs, don't use chmod to change file permissions. There's no rule prohibiting you from doing so, but it could cause unexpected problems. For example, if you use chmod to change the permissions for the group owner, chmod might modify the mask in the ACL to enable your specified permissions for the group to take effect. This could cause a security breach by opening up access to other groups specified in the ACL.

Finally, know that ACLs are a UFS file system attribute and are not currently available on any other type of file system. So, if you copy files to a floppy disk formatted with PCFS or restore files to the /tmp file system (which is typically TMPFS), all ACL entries will be lost. Normally, this isn't an issue, but if you accidentally restore files into /tmp instead of /var/tmp, it could cause problems.




Solaris 9. Sun Certified System Administrator Study Guide
Solaris 9 Sun Certified System Administrator Study Guide
ISBN: 0782141811
EAN: 2147483647
Year: 2003
Pages: 194

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