This chapter describes the procedures for securing files in the Solaris environment.
This is a list of the step-by-step instructions in this chapter.
This section describes the features that constitute a file's security.
For each file, there are three classes of users that specify the levels of security:
user – The file or directory owner, which is usually the user who created the file. The owner of a file can decide who has the right to read it, to write to it (make changes to it), or, if it is a command, to execute it.
group – Members of a group.
others – All other users who are not the file owner or group owner.
Only the owner of the file or root can assign or modify file permissions.
The following table lists and describes the permissions that you can give to each user class for a file.
Table 15–1 File Permissions
Symbol |
Permission |
Description |
---|---|---|
r |
Read |
Designated users can open and read the contents of a file. |
w |
Write |
Designated users can write to the file (modify its contents), add to it, or delete it. |
x |
Execute |
Designated users can execute the file (if it is a program or shell script), or run the program with one of the exec(2) system calls. |
- |
Denied |
Designated users cannot read, write, or execute the file. |
These file permissions apply to special files such as devices, sockets, and named pipes (FIFOs), as they do to regular files.
For a symbolic link, the permissions that apply are the permissions of the file that the link points to.
The following table lists and describes the permissions that you can give to each user class for a directory.
Table 15–2 Directory Permissions
Symbol |
Permission |
Description |
---|---|---|
r |
Read |
Designated users can list files in the directory. |
w |
Write |
Designated users can add or remove files or links in the directory. |
x |
Execute |
Designated users can open or execute files in the directory. They also can make the directory and the directories beneath it current. |
You can protect the files in a directory (and in its subdirectories) by disallowing access to that directory by setting restrictive file permissions. Note, however, that superuser has access to all files and directories on the system.
Three special types of permissions are available for executable files and public directories. When these permissions are set, any user who runs that executable file assumes the user ID of the owner (or group) of the executable file.
You must be extremely careful when you set special permissions, because special permissions constitute a security risk. For example, a user can gain superuser privileges by executing a program that sets the user ID (UID) to root. Also, all users can set special permissions for files they own, which constitutes another security concern.
You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. To search for and list all of the files that use these permissions, see How to Find Files With setuid Permissions. A suspicious listing grants ownership of such a program to a user rather than to root or bin.
When set-user identification (setuid) permission is set on an executable file, a process that runs this file is granted access based on the owner of the file (usually root), rather than the user who is running the executable file. This special permission allows a user to access files and directories that are normally only available to the owner. For example, the setuid permission on the passwd command makes it possible for a user to change passwords, assuming the permissions of the root ID:
-r-sr-sr-x 3 root sys 104580 Sep 16 12:02 /usr/bin/passwd |
This special permission presents a security risk, because some determined users can find a way to maintain the permissions that are granted to them by the setuid process even after the process has finished executing.
The use of setuid permissions with the reserved UIDs (0–100) from a program might not set the effective UID correctly. Use a shell script instead or avoid using the reserved UIDs with setuid permissions.
The set-group identification (setgid) permission is similar to setuid, except that the process's effective group ID (GID) is changed to the group owner of the file, and a user is granted access based on permissions granted to that group. The /usr/bin/mail command has setgid permissions:
-r-x--s--x 1 root mail 63628 Sep 16 12:01 /usr/bin/mail |
When setgid permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs, not the group to which the creating process belongs. Any user who has write and execute permissions in the directory can create a file there. However, the file belongs to the group that owns the directory, not to the user's group ownership.
You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. To search for and list all of the files that use these permissions, see How to Find Files With setuid Permissions. A suspicious listing grants group ownership of such a program to a user rather than to root or bin.
The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the owner of the file, the owner of the directory, or by root. This special permission prevents a user from deleting other users' files from public directories such as /tmp:
drwxrwxrwt 7 root sys 400 Sep 3 13:37 tmp |
Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system.
When you create a file or directory, it has a default set of permissions. These default permissions are determined by the umask setting in the /etc/profile file, or in your .cshrc or .login file. By default, the system sets the permissions on a text file to 666, which grants read and write permission to user, group, and others, and to 777 on a directory or executable file.
The value assigned by the umask command is subtracted from the default. This process has the effect of denying permissions in the same way that the chmod command grants them. For example, while the chmod 022 command grants write permission to group and others, the umask 022 command denies write permission for group and others.
The following table shows some typical umask settings, and the effect on an executable file.
Table 15–3 umask Settings for Different Security Levels
Level of Security |
umask Setting |
Permissions Disallowed |
---|---|---|
Permissive (744) |
022 |
w for group and others |
Moderate (740) |
027 |
w for group, rwx for others |
Moderate (741) |
026 |
w for group, rw for others |
Severe (700) |
077 |
rwx for group and others |
For more information on setting the umask value, see the umask(1) man page.
This section describes how to display file information.
Display information about all the files in a directory by using the ls command.
$ ls -la |
-l |
Displays the long format that includes user and group ownership and file permissions. |
-a |
Displays all files, including hidden files that begin with a dot (.). |
Each line in the display has the following information about a file:
Type of file
A file can be one of seven types. The following table lists the possible file types.
Table 15–4 File Types
Symbol |
Type |
---|---|
- |
Text or program |
D |
Door |
d |
Directory |
b |
Block special file |
c |
Character special file |
p |
Named pipe (FIFO) |
l |
Symbolic link |
s |
Socket |
Permissions; see Table 15–1 and Table 15–2 for descriptions
Number of hard links
Owner of the file
Group of the file
Size of the file, in bytes
Date the file was created or the last date that the file was changed
Name of the file
The following example displays the partial list of the files in the /sbin directory.
$ cd /sbin $ ls -la total 13456 drwxr-xr-x 2 root sys 512 Sep 1 14:11 . drwxr-xr-x 29 root root 1024 Sep 1 15:40 .. -r-xr-xr-x 1 root bin 218188 Aug 18 15:17 autopush lrwxrwxrwx 1 root root 21 Sep 1 14:11 bpgetfile -> ... -r-xr-xr-x 1 root bin 505556 Aug 20 13:24 dhcpagent -r-xr-xr-x 1 root bin 456064 Aug 20 13:25 dhcpinfo -r-xr-xr-x 1 root bin 272360 Aug 18 15:19 fdisk -r-xr-xr-x 1 root bin 824728 Aug 20 13:29 hostconfig -r-xr-xr-x 1 root bin 603528 Aug 20 13:21 ifconfig -r-xr-xr-x 1 root sys 556008 Aug 20 13:21 init -r-xr-xr-x 2 root root 274020 Aug 18 15:28 jsh -r-xr-xr-x 1 root bin 238736 Aug 21 19:46 mount -r-xr-xr-x 1 root sys 7696 Aug 18 15:20 mountall . . . |
This section describes how to change the ownership and group ownership of a file.
By default, the owner cannot use the chown command to change the owner of a file or directory. However, you can enable the owner to use the chown command by adding the following line to the system's /etc/system file and rebooting the system.
set rstchown = 0 |
For more information, see chown(1).
In addition, the owner can only use the chgrp command to change the group of a file to a group in which the owner belongs by default. For example, if the owner of a file only belongs to the staff and sysadm groups, the owner can only change the group of a file to staff or sysadm group.
However, you can enable the owner to change the group of a file to a group in which the owner doesn't belong by adding the following line to the system's /etc/system file and rebooting the system.
set rstchown = 0 |
For more information, see chgrp(1).
Also, be aware that there can be other restrictions on changing ownership and groups on NFS-mounted file systems.
Use the following procedure to change the ownership of a file.
Change the owner of a file by using the chown command.
# chown new-owner filename |
new-owner |
Specifies the user name or UID of the new owner of the file or directory. |
filename |
Specifies the file or directory. |
Verify that the owner of the file has changed.
# ls -l filename |
In the following example, the ownership on myfile is changed to the user rimmer.
# chown rimmer myfile # ls -l myfile -rw-r--r-- 1 rimmer scifi 112640 May 24 10:49 myfile |
Use the following procedure to change the group ownership of a file.
Change the group owner of a file by using the chgrp command.
$ chgrp group filename |
group |
Specifies the group name or GID of the new group of the file or directory. |
filename |
Specifies the file or directory. |
For information on setting up groups, see “Managing User Accounts and Groups (Overview)” in System Administration Guide: Basic Administration.
Verify that the group owner of the file has changed.
$ ls -l filename |
In the following example, the group ownership on myfile is changed to the group scifi.
$ chgrp scifi myfile $ ls -l myfile -rwxrw-- 1 rimmer scifi 12985 Nov 12 16:28 myfile |
The chmod command enables you to change the permissions on a file. You must be superuser or the owner of a file or directory to change its permissions.
You can use the chmod command to set permissions in either of two modes:
Absolute Mode – Use numbers to represent file permissions (the method most commonly used to set permissions). When you change permissions by using the absolute mode, you represent permissions for each triplet by an octal mode number.
Symbolic Mode – Use combinations of letters and symbols to add or remove permissions.
The following table lists the octal values for setting file permissions in absolute mode. You use these numbers in sets of three to set permissions for owner, group, and other (in that order). For example, the value 644 sets read and write permissions for owner, and read-only permissions for group and other.
Table 15–5 Setting File Permissions in Absolute Mode
Octal Value |
File Permissions Set |
Permissions Description |
---|---|---|
0 |
--- |
No permissions |
1 |
--x |
Execute permission only |
2 |
-w- |
Write permission only |
3 |
-wx |
Write and execute permissions |
4 |
r-- |
Read permission only |
5 |
r-x |
Read and execute permissions |
6 |
rw- |
Read and write permissions |
7 |
rwx |
Read, write, and execute permissions |
You can set special permissions on a file in absolute or symbolic modes. However, you cannot set or remove setuid permissions on a directory by using absolute mode. You must use symbolic mode. In absolute mode, you set special permissions by adding a new octal value to the left of the permission triplet. The following table lists the octal values to set special permissions on a file.
Table 15–6 Setting Special Permissions in Absolute Mode
Octal Value |
Special Permissions Set |
---|---|
1 |
Sticky bit |
2 |
setguid |
4 |
setuid |
The following table lists the symbols for setting file permissions in symbolic mode. Symbols can specify whose permissions are to be set or changed, the operation to be performed, and the permissions that are being assigned or changed.
Table 15–7 Setting File Permissions in Symbolic Mode
Symbol |
Function |
Description |
---|---|---|
u |
Who |
User (owner) |
g |
Who |
Group |
o |
Who |
Others |
a |
Who |
All |
= |
Operator |
Assign |
+ |
Operator |
Add |
- |
Operator |
Remove |
r |
Permission |
Read |
w |
Permission |
Write |
x |
Permission |
Execute |
l |
Permission |
Mandatory locking, setgid bit is on, group execution bit is off |
s |
Permission |
setuid or setgid bit is on |
S |
Permission |
suid bit is on, user execution bit is off |
t |
Permission |
Sticky bit is on, execution bit for others is on |
T |
Permission |
Sticky bit is on, execution bit for others is off |
The who operator permission designations in the function column specifies the symbols that change the permissions on the file or directory.
who |
Specifies whose permissions are to be changed. |
operator |
Specifies the operation to be performed. |
permissions |
Specifies what permissions are to be changed. |
Use the following procedure to change permissions in absolute mode.
If you are not the owner of the file or directory, become superuser or assume an equivalent role.
Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.
Change permissions in absolute mode by using the chmod command.
$ chmod nnn filename |
nnn |
Specifies the octal values that represent the permissions for the file owner, file group, and others, in that order. See Table 15–5 for the list of valid octal values. |
filename |
Specifies the file or directory. |
If you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for additional users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.
Verify that the permissions of the file have changed.
$ ls -l filename |
In the following example, the permissions of a public directory are changed from 744 (read, write, execute; read-only; and read-only) to 755 (read, write, execute; read and execute; and read and execute).
$ ls -ld public_dir drwxr--r-- 1 ignatz staff 6023 Aug 5 12:06 public_dir $ chmod 755 public_dir $ ls -ld public_dir drwxr-xr-x 1 ignatz staff 6023 Aug 5 12:06 public_dir |
In the following example, the permissions of an executable shell script are changed from read and write to read, write, and execute.
$ ls -l my_script -rw------- 1 ignatz staff 6023 Aug 5 12:06 my_script $ chmod 700 my_script $ ls -l my_script -rwx------ 1 ignatz staff 6023 Aug 5 12:06 my_script |
Use the following procedure to change special permissions in absolute mode.
If you are not the owner of the file or directory, become superuser or assume an equivalent role.
Only the current owner or superuser can use the chmod command to change the special permissions on a file or directory.
Change special permissions in absolute mode by using the chmod command.
$ chmod nnnn filename |
nnnn |
Specifies the octal values that change the permissions on the file or directory. The first octal value on the left sets the special permissions on the file. For the list of valid octal values for the special permissions, see Table 15–6. |
filename |
Specifies the file or directory. |
If you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for additional users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.
Verify that the permissions of the file have changed.
$ ls -l filename |
In the following example, the setuid permission is set on the dbprog file.
$ chmod 4555 dbprog $ ls -l dbprog -r-sr-xr-x 1 db staff 12095 May 6 09:29 dbprog |
In the following example, the setgid permission is set on the dbprog2 file.
$ chmod 2551 dbprog2 $ ls -l dbprog2 -r-xr-s--x 1 db staff 24576 May 6 09:30 dbprog2 |
In the following example, the sticky bit permission is set on the public_dir directory.
$ chmod 1777 public_dir $ ls -ld public_dir drwxrwxrwt 2 ignatz staff 512 May 15 15:27 public_dir |
Use the following procedure to change permissions in symbolic mode.
If you are not the owner of the file or directory, become superuser.
Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.
Change permissions in symbolic mode by using the chmod command.
$ chmod who operator permission filename |
who operator permission |
who specifies whose permissions are to be changed, operator specifies the operation to be performed, and permission specifies what permissions are to be changed. For the list of valid symbols, see Table 15–7. |
filename |
Specifies the file or directory. |
Verify that the permissions of the file have changed.
$ ls -l filename |
In the following example, read permission are taken away from others.
$ chmod o-r filea |
In the following example, read and execute permissions are added for user, group, and others.
$ chmod a+rx fileb |
In the following example, read, write, and execute permissions are assigned to group.
$ chmod g=rwx filec |
You should monitor your system for any unauthorized use of the setuid and setgid permissions on programs to gain superuser privileges. A suspicious listing grants ownership of such a program to a user rather than to root or bin.
Use the following procedure to find files with setuid permissions.
Find files with setuid permissions by using the find command.
# find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename |
find directory |
Checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail. |
-user root |
Displays files owned only by root. |
-perm -4000 |
Displays files only with permissions set to 4000. |
-exec ls -ldb |
Displays the output of the find command in ls -ldb format. |
>/tmp/filename |
Writes results to this file. |
Display the results in /tmp/filename.
# more /tmp/filename |
If you need background information about setuid permissions, see setuid Permission.
# find / -user root -perm -4000 -exec ls -ldb {} \; > /tmp/ckprm # cat /tmp/ckprm -r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at -r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab ---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct -r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir -r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin -r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched ---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh -r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df -rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp -r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd -r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su |
This output shows that a user named rar has made a personal copy of /usr/bin/sh, and has set the permissions as setuid to root. As a result, rar can execute /usr/rar/bin/sh and become the privileged user. If you want to save this output for future reference, move the file out of the /tmp directory.
A number of security bugs are related to default executable stacks when their permissions are set to read, write, and execute. While stacks with execute permissions are allowed, most programs can function correctly without using executable stacks.
The noexec_user_stack variable (available starting in the Solaris 2.6 release) enables you to specify whether stack mappings are executable. By default, the variable is set to zero, except on 64-bit applications, which provides ABI-compliant behavior. If the variable is set to non-zero, the system marks the stack of every process in the system as readable and writable, but not executable.
Once this variable is set, programs that attempt to execute code on their stack are sent a SIGSEGV signal, which usually results in the program terminating with a core dump. Such programs also generate a warning message that includes the name of the offending program, the process ID, and the real UID of the user who ran the program. For example:
a.out[347] attempt to execute code on stack by uid 555 |
The message is logged by the syslog daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf file, which means that the message is sent to both the console and to the /var/adm/messages file. For more information, see the syslogd(1M) and syslog.conf(4) man pages.
This message is useful for observing potential security problems, as well as to identify valid programs that depend upon executable stacks that have been prevented from correct operation by setting this variable. If the administrator does not want any messages logged, then the noexec_user_stack_log variable can be set to zero to disable it in the /etc/system file, though the SIGSEGV signal can continue to cause the executing program to core dump.
You can use mprotect if you want programs to explicitly mark their stack as executable. For more information, see the mprotect(2) man page.
Because of hardware limitations, the capability of catching and reporting executable stack problems is only available on sun4m and sun4u platforms.
Become superuser or assume an equivalent role.
Edit the /etc/system file and add the following line:
set noexec_user_stack=1 |
Reboot the system.
# init 6 |
Become superuser or assume an equivalent role.
Edit the /etc/system file and add the following line:
set noexec_user_stack_log=0 |
Reboot the system.
# init 6 |
Traditional UNIX file protection provides read, write, and execute permissions for the three user classes: file owner, file group, and other. An ACL provides better file security by enabling you to define file permissions for the file owner, file group, other, specific users and groups, and default permissions for each of those categories.
For example, if you wanted everyone in a group to be able to read a file, you would simply give group read permissions on that file. Now, assume you wanted only one person in the group to be able to write to that file. Standard UNIX doesn't provide that level of file security. However, this dilemma is perfect for ACLs.
ACL entries are the way to define an ACL on a file, and they are set through the setfacl command. ACL entries consist of the following fields separated by colons:
entry-type:[uid|gid]:perms |
entry-type |
Is the type of ACL entry on which to set file permissions. For example, entry-type can be user (the owner of a file) or mask (the ACL mask). For a listing of ACL entries, see Table 15–8 and Table 15–9. |
uid |
Is the user name or user ID (UID). |
gid |
Is the group name or group ID (GID). |
perms |
Represents the permissions that are set on entry-type. perms can be indicated by the symbolic characters rwx or a number (the same permissions numbers that are used with the chmod command). |
The following example shows an ACL entry that sets read and write permissions for the user nathan.
user:nathan:rw- |
UFS file system attributes such as ACLs are supported in UFS file systems only. Thus, if you restore or copy files with ACL entries into the /tmp directory, which is usually mounted as a TMPFS file system, the ACL entries will be lost. Use the /var/tmp directory for temporary storage of UFS files.
The following table lists the valid ACL entries that you might use when setting file ACLs. The first three ACL entries provide the basic UNIX file protection.
Table 15–8 ACL Entries for Files
ACL Entry |
Description |
---|---|
u[ser]::perms |
File owner permissions. |
g[roup]::perms |
File group permissions. |
o[ther]:perms |
Permissions for users other than the file owner or members of the file group. |
m[ask]:perms |
The ACL mask. The mask entry indicates the maximum permissions that are allowed for users (other than the owner) and for groups. The mask is a quick way to change permissions on all the users and groups. For example, the mask:r-- mask entry indicates that users and groups cannot have more than read permissions, even though they might have write and execute permissions. |
u[ser]:uid:perms |
Permissions for a specific user. For uid, you can specify either a user name or a numeric UID. |
g[roup]:gid:perms |
Permissions for a specific group. For gid, you can specify either a group name or a numeric GID. |
In addition to the ACL entries that are described in Table 15–8, you can set default ACL entries on a directory. Files or directories created in a directory that has default ACL entries will have the same ACL entries as the default ACL entries. Table 15–9 lists the default ACL entries for directories.
When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the file owner, file group, others, and the ACL mask. These entries are required and are the first four default ACL entries in the following table.
Table 15–9 Default ACL Entries for Directories
Default ACL Entry |
Description |
---|---|
d[efault]:u[ser]::perms |
Default file owner permissions. |
d[efault]:g[roup]::perms |
Default file group permissions. |
d[efault]:o[ther]:perms |
Default permissions for users other than the file owner or members of the file group. |
d[efault]:m[ask]:perms |
Default ACL mask. |
d[efault]:u[ser]:uid:perms |
Default permissions for a specific user. For uid, you can specify either a user name or a numeric UID. |
d[efault]:g[roup]:gid:perms |
Default permissions for a specific group. For gid, you can specify either a group name or a numeric GID. |
Set an ACL on a file by using the setfacl command.
$ setfacl -s user::perms,group::perms,other:perms,mask:perms,acl-entry-list filename ... |
-s |
Sets an ACL on the file. If a file already has an ACL, it is replaced. This option requires at least the file owner, file group, and other entries. |
user::perms |
Specifies the file owner permissions. |
group::perms |
Specifies the file group permissions. |
other:perms |
Specifies the permissions for users other than the file owner or members of the file group. |
mask:perms |
Specifies the permissions for the ACL mask. The mask indicates the maximum permissions that are allowed for users (other than the owner) and for groups. |
acl-entry-list |
Specifies the list of one or more ACL entries to set for specific users and groups on the file or directory. You can also set default ACL entries on a directory. Table 15–8 and Table 15–9 show the valid ACL entries. |
filename ... |
Specifies one or more files or directories on which to set the ACL, separated by a space. |
If an ACL already exists on the file, the -s option will replace the entire ACL with the new ACL.
For more information, see setfacl(1).
Verify that an ACL was set on the file or verify which ACL entries were set on the file.
$ getfacl filename |
For more information, see How to Check If a File Has an ACL.
In the following example, the file owner permissions are set to read and write, file group permissions are set to read only, and other permissions are set to none on the ch1.doc file. In addition, the user george is given read and write permissions on the file, and the ACL mask permissions are set to read and write, which means that no user or group can have execute permissions.
$ setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:george:rw- ch1.doc $ ls -l total 124 -rw-r-----+ 1 nathan sysadmin 34816 Nov 11 14:16 ch1.doc -rw-r--r-- 1 nathan sysadmin 20167 Nov 11 14:16 ch2.doc -rw-r--r-- 1 nathan sysadmin 8192 Nov 11 14:16 notes $ getfacl ch1.doc # file: ch1.doc # owner: nathan # group: sysadmin user::rw- user:george:rw- #effective:rw- group::r-- #effective:r-- mask:rw- other:--- |
In the following example, the file owner permissions are set to read, write, and execute, file group permissions are set to read only, other permissions are set to none, and the ACL mask permissions are set to read on the ch2.doc file. In addition, the user george is given read and write permissions. However, due to the ACL mask, the permissions for george are read only.
$ setfacl -s u::7,g::4,o:0,m:4,u:george:7 ch2.doc $ getfacl ch2.doc # file: ch2.doc # owner: nathan # group: sysadmin user::rwx user:george:rwx #effective:r-- group::r-- #effective:r-- mask:r-- other:--- |
Copy a file's ACL to another file by redirecting the getfacl output.
$ getfacl filename1 | setfacl -f - filename2 |
filename1 |
Specifies the file from which to copy the ACL. |
filename2 |
Specifies the file on which to set the copied ACL. |
In the following example, the ACL on ch2.doc is copied to ch3.doc.
$ getfacl ch2.doc | setfacl -f - ch3.doc |
Check if a file has an ACL by using the ls command.
$ ls -l filename |
filename specifies the file or directory.
In the output, a plus sign (+) to the right of the mode field indicates that the file has an ACL.
Unless you have added ACL entries for additional users or groups on a file, a file is considered to be a “trivial” ACL and the plus sign (+) will not display.
The following example shows that the ch1.doc file has an ACL, because the listing has a plus sign (+) to the right of the mode field.
$ ls -l ch1.doc -rwxr-----+ 1 nathan sysadmin 167 Nov 11 11:13 ch1.doc |
Modify ACL entries on a file by using the setfacl command.
$ setfacl -m acl-entry-list filename ... |
-m |
Modifies the existing ACL entry. |
acl-entry-list |
Specifies the list of one or more ACL entries to modify on the file or directory. You can also modify default ACL entries on a directory. Table 15–8 and Table 15–9 show the valid ACL entries. |
filename ... |
Specifies one or more files or directories, separated by a space. |
Verify that the ACL entries were modified on the file by using the getfacl command.
$ getfacl filename |
In the following example, the permissions for the user george are modified to read and write.
$ setfacl -m user:george:6 ch3.doc $ getfacl ch3.doc # file: ch3.doc # owner: nathan # group: staff user::rw- user::george:rw- #effective:r-- group::r- #effective:r-- mask:r-- other:r- |
In the following example, the default permissions for the group staff are modified to read and the default ACL mask permissions are modified to read and write on the book directory.
$ setfacl -m default:group:staff:4,default:mask:6 book |
Delete ACL entries from a file by using the setfacl command.
$ setfacl -d acl-entry-list filename ... |
-d |
Deletes the specified ACL entries. |
acl-entry-list |
Specifies the list of ACL entries (without specifying the permissions) to delete from the file or directory. You can only delete ACL entries and default ACL entries for specific users and groups. Table 15–8 and Table 15–9 show the valid ACL entries. |
filename ... |
Specifies one or more files or directories, separated by a space. |
Alternately, you can use setfacl -s to delete all the ACL entries on a file and replace them with the new ACL entries that are specified.
To verify that the ACL entries were deleted from the file, by using the getfacl command.
$ getfacl filename |
In the following example, the user george is deleted from the ch4.doc file.
$ setfacl -d user:george ch4.doc |
Display ACL entries for a file by using the getfacl command.
$ getfacl [-a | -d] filename ... |
-a |
Displays the file name, file owner, file group, and ACL entries for the specified file or directory. |
-d |
Displays the file name, file owner, file group, and default ACL entries for the specified directory. |
filename ... |
Specifies one or more files or directories, separated by a space. |
If you specify multiple file names on the command line, the ACL entries are displayed with a blank line between each entry.
The following example shows all the ACL entries for the ch1.doc file. The #effective: note beside the user and group entries indicates what the permissions are after being modified by the ACL mask.
$ getfacl ch1.doc # file: ch1.doc # owner: nathan # group: sysadmin user::rw- user:george:r-- #effective:r-- group::rw- #effective:rw- mask:rw- other:--- |
The following example shows the default ACL entries for the book directory.
$ getfacl -d book # file: book # owner: nathan # group: sysadmin user::rwx user:george:r-x #effective:r-x group::rwx #effective:rwx mask:rwx other:--- default:user::rw- default:user:george:r-- default:group::rw- default:mask:rw- default:other:--- |