Command Center

Overview
In this article, learn to control file access through correct use of file and directory permissions and ownerships. Learn to:

• Manage access permissions on both regular and special files as well as directories
• Maintain security using access modes such as suid, sgid, and the sticky bit
• Change the file creation mask
• Grant file access to group members

Unless otherwise noted, the examples in this article use Fedora 13 with a 2.6.34 kernel. Your results on other systems may differ.
This article helps you prepare for Objective 104.5 in Topic 104 of the Linux Professional Institute's Junior Level Administration (LPIC-1) exam 101. The objective has a weight of 3.
We introduced some of the file and group ownership concepts of this article in our previous article "Learn Linux 101: Manage disk quotas." This article will help you understand those concepts more completely.
Prerequisites
To get the most from the articles in this series, you should have a basic knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. Sometimes different versions of a program will format output differently, so your results may not always look exactly like the listings and figures shown here.
User and groups
By now, you know that Linux is a multiuser system and that each user belongs to one primary group and possibly additional groups. It is also possible to log in as one user and become another user using the su or sudo -s commands. Ownership of files in Linux and access authority are closely related to user ids and groups, so let's review some basic user and group information.
Who am I?
If you have not become another user, your id is still the one you used to log in. If you have become another user, your prompt may include your user id, as most of the examples in this article do. If your prompt does not include your user id, then you can use the whoami command to check your current effective id. Listing 1 shows some examples where the prompt strings (from the PS1 environment variable) are different from the other examples in this article. Having your id in the prompt string can be a useful feature.

Listing 1. Determining effective user id

/home/ian$ whoami tom /home/ian$ exit exit $ whoami ian

What groups am I in?
Similarly, you can find out what groups you are in by using the groups command. You can find out both user and group information using the id command. Add a user id parameter to either groups or id to see information for that user id instead of the current user id. See Listing 2 for some examples. Note that without a userid, the id command will also display SELinux context as well as basic id information.

Listing 2. Determining group membership

[ian@echidna ~]$ id uid=1000(ian) gid=1000(ian) groups=1000(ian),505(development),8093(editor) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [ian@echidna ~]$ id ian uid=1000(ian) gid=1000(ian) groups=1000(ian),8093(editor),505(development) [ian@echidna ~]$ groups ian development editor [ian@echidna ~]$ id tom uid=1012(tom) gid=1012(tom) groups=1012(tom),505(development) [ian@echidna ~]$ groups tom tom : tom development [ian@echidna ~]$ su tom Password: [tom@echidna ian]$ groups tom development [tom@echidna ian]$ groups ian ian : ian editor development

File ownership and permissions
Just as every user has an id and is a member of one primary group, so every file on a Linux system has one owner and one group associated with it.
Ordinary files
Use the ls -l command to display the owner and group.

Listing 3. Determining file ownership

[ian@echidna ~]$ ls -l /bin/bash .bashrc helloworld.C -rw-r--r--. 1 ian ian 124 Mar 31 2010 .bashrc -rwxr-xr-x. 1 root root 943360 May 21 2010 /bin/bash -rw-rw-r--. 1 ian development 116 Nov 30 10:21 helloworld.C

In this particular example, user ian's .bashrc file is owned by him and is in the ian group, which is his primary group. Similarly, /bin/bash is owned by user root and is in the group root. However, helloworld.C is owned by user ian, but its group is development. User names and groups names come from separate namespaces, so a given name may be both a user name and a group name. In fact, many distributions default to creating a matching group for each new user.
The Linux permission model has three types of permission for each filesystem object. The permissions are read (r), write (w), and execute (x). Write permission includes the ability to alter or delete an object. In addition, these permissions are specified separately for the file's owner, members of the file's group, and everyone else.
Referring back to the first column of Listing 3, notice that it contains an eleven-character string. The eleventh character is a recent addition. We'll discuss it in a moment. The first character describes the type of object (- for an ordinary file in this example) and the remaining nine characters represent three groups of three characters. The first group indicates the read, write, and execute permissions for the file's owner. A - indicates that the corresponding permission is not granted. So user ian can read and write the .bashrc file, but not execute it; while root can read, write, and execute the /bin/bash file. The second group indicates the read, write, and execute permissions for the file's group. Members of the development group can read or write ian's helloworld.C file, while everyone else can only read it. Similarly, members of the root group and everyone else can read or execute the /bin/bash file.
Directories
Directories use the same permissions flags as regular files, but they are interpreted differently. Read permission for a directory allows a user with that permission to list the contents of the directory. Write permission means a user with that permission can create or delete files in the directory. Execute permission allows the user to enter the directory and access any subdirectories. Without execute permission, the filesystem objects inside a directory are not accessible. Without read permission, the filesystem objects inside a directory are not viewable in a directory listing, but these objects can still be accessed as long as you know the full path to the object on disk. Listing 4 is a very artificial example to illustrate these points.

Listing 4. Permissions and directories

[ian@echidna ~]$ ls -l /home total 32 drwxr-x---. 38 editor editor 12288 Nov 30 10:49 editor drwxr-x---. 4 greg development 4096 Nov 30 12:44 greg drwx------. 21 gretchen gretchen 4096 Nov 30 11:26 gretchen drwxr-xr-x. 41 ian ian 4096 Nov 30 10:51 ian drwx------. 21 ianadmin ianadmin 4096 May 28 2010 ianadmin d-wx--x--x. 21 tom tom 4096 Nov 30 11:30 tom [ian@echidna ~]$ ls -a ~greg/.ba* /home/greg/.bash_history /home/greg/.bash_profile /home/greg/.bash_logout /home/greg/.bashrc [ian@echidna ~]$ ls -a ~gretchen ls: cannot open directory /home/gretchen: Permission denied [ian@echidna ~]$ ls -a ~tom ls: cannot open directory /home/tom: Permission denied [ian@echidna ~]$ head -n 3 ~tom/.bashrc # .bashrc # Source global definitions

The first character of a long listing describes the type of object (d for a directory). User greg's home directory has read and execute permission for members of the development group, so users tom and ian can list the directory. User gretchen's home directory has neither read nor execute permission for the gretchen group or other users, so user ian cannot access it. User tom's home has execute but not read permission, so user ian cannot list the contents, but can access objects within the directory if he knows they exist.
Other filesystem objects
The output from ls -l may contain filesystem objects other than files and directories as shown by the first character in the listing. We will see more of these later in this article, but for now, note the possible types of objects.

Table 1. Filesystem object types

Code	Object type
-	Regular file
d	Directory
l	Symbolic link
c	Character special device
b	Block special device
p	FIFO
s	Socket

The eleventh character
The eleventh character in a long listing from the ls command is a recent enhancement, so some distributions may still show only the first ten characters. In other cases, the eleventh character is a space, so you may not notice it. This character specifies whether an alternate access method applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. The method might be an access control list for example. GNU ls uses a '.' (dot) character to signify a file with only an SELinux security context. Files with any other combination of alternate access methods are marked with the '+' (plus) character.
Changing permissions
Adding permissions
Suppose you create a "Hello world" shell script. When you first create the script, it will usually not be executable. Use the chmod command with the +x option to add the execute permissions as shown in Listing 5.

Listing 5. Creating an executable shell script

[ian@echidna ~]$ echo 'echo "Hello world!"'>hello.sh [ian@echidna ~]$ ls -l hello.sh -rw-rw-r--. 1 ian ian 20 Nov 30 13:05 hello.sh [ian@echidna ~]$ ./hello.sh bash: ./hello.sh: Permission denied [ian@echidna ~]$ chmod +x hello.sh [ian@echidna ~]$ ./hello.sh Hello world! [ian@echidna ~]$ ls -l hello.sh -rwxrwxr-x. 1 ian ian 20 Nov 30 13:05 hello.sh

You can use +r to set the read permissions, and +w to set the write permissions in a similar manner. In fact, you can use any combination of r, w, and x together. For example, using chmod +rwx would set all the read, write, and execute permissions for a file. This form of chmod adds permissions that are not already set.
Being selective
You may have noticed in the above example that execute permission was set for the owner, group, and others. To be more selective, you may prefix the mode expression with u to set the permission for users, g to set it for groups, and o to set it for others. Specifying a sets the permission for all users, which is equivalent to omitting it. Listing 6 shows how to add user and group write and execute permissions to another copy of the shell script.

Listing 6. Selectively adding permissions

[ian@echidna ~]$ echo 'echo "Hello world!"'>hello2.sh [ian@echidna ~]$ chmod ug+xw hello2.sh [ian@echidna ~]$ ls -l hello2.sh -rwxrwxr--. 1 ian ian 20 Nov 30 13:08 hello2.sh

Removing permissions
Sometimes you need to remove permissions rather than add them. Simply change the + to a -, and you remove any of the specified permissions that are set. Listing 7 shows how to remove all permissions for other users on the two shell scripts.

Listing 7. Removing permissions

[ian@echidna ~]$ ls -l hello*.sh -rwxrwxr--. 1 ian ian 20 Nov 30 13:08 hello2.sh -rwxrwxr-x. 1 ian ian 20 Nov 30 13:05 hello.sh [ian@echidna ~]$ chmod o-xrw hello*.sh [ian@echidna ~]$ ls -l hello*.sh -rwxrwx---. 1 ian ian 20 Nov 30 13:08 hello2.sh -rwxrwx---. 1 ian ian 20 Nov 30 13:05 hello.sh

Note that you can change permissions on more than one file at a time. As with some other commands you met in the articles for topic 103, you can even use the -R (or --recursive) option to operate recursively on directories and files.
Setting permissions
Now that you can add or remove permissions, you may wonder how to set just a specific set of permissions. Do this using = instead of + or -. To set the permissions on the above scripts so that other users have no access rights, you could use chmod o= hello*, instead of the command we used to remove permissions.
If you want to set different permissions for user, group, or other, you can separate different expressions by commas; for example, ug=rwx,o=rx, or you can use numeric permissions, which are described next.
Octal permissions
So far you have used symbols (ugoa and rxw) to specify permissions. There are three possible permissions in each group. You can also set permissions using octal numbers instead of symbols. Permissions set in this way use up to four octal digits. We will look at the first digit when we discuss attributes. The second digit defines user permissions, the third group permissions and the fourth other permissions. Each of these three digits is constructed by adding the desired permissions settings: read (4), write (2), and execute (1). In the example for hello.sh in Listing 5, the script was created with permissions -rw-r--r--, corresponding to octal 644. Setting execute permission for everyone changed the mode to 755.
Using numeric permissions is very handy when you want to set all the permissions at once without giving the same permissions to each of the groups. Use Table 2 as a handy reference for octal permissions.

Table 2. Numeric permissions

Symbolic	Octal
rwx	7
rw-	6
r-x	5
r--	4
-wx	3
-w-	2
--x	1
---	0

Access modes
When you log in, the new shell process runs with your user and group ids. These are the permissions that govern your access to any files on the system. This usually means that you cannot access files belonging to others and cannot access system files. In fact, we as users are totally dependent on other programs to perform operations on our behalf. Because the programs you start inherit your user id, they cannot access any filesystem objects for which you haven't been granted access.
An important example is the /etc/passwd file, which cannot be changed by normal users directly, because write permission is enabled only for root: However, normal users need to be able to modify /etc/passwd somehow, whenever they need to change their password. So, if the user is unable to modify this file, how can this be done?
suid and sgid
The Linux permissions model has two special access modes called suid (set user id) and sgid (set group id). When an executable program has the suid access modes set, it will run as if it had been started by the file's owner, rather than by the user who really started it. Similarly, with the sgid access modes set, the program will run as if the initiating user belonged to the file's group rather than to his own group. Either or both access modes may be set.
Listing 8 shows that the passwd executable is owned by root:

Listing 8. suid access mode on /usr/bin/passwd

[ian@echidna ~]$ ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 34368 Apr 6 2010 /usr/bin/passwd

Note that in place of an x in the user's permission triplet, there's an s. This indicates that, for this particular program, the suid and executable bits are set. So when passwd runs, it will execute as if the root user had launched it with full superuser access, rather than that of the user who ran it. Because passwd runs with root access, it can modify /etc/passwd.
The suid and sgid bits occupy the same space as the x bits for user and group in a long directory listing. If the file is executable, the suid or sgid bits, if set, will be displayed as lowercase s, otherwise they are displayed as uppercase S.
While suid and sgid are handy, and even necessary in many circumstances, improper use of these access mode can allow breaches of a system's security. You should have as few suid programs as possible. The passwd command is one of the few that must be suid.
Setting suid and sgid
The suid and sgid bits are set and reset symbolically using the letter s; for example, u+s sets the suid access mode, and g-s removes the sgid mode. In the octal format, suid has the value 4 in the first (high order) digit, while sgid has the value 2.
Directories and sgid
When a directory has the sgid mode enabled, any files or directories created in it will inherit the group id of the directory. This is particularly useful for directory trees that are used by a group of people working on the same project. Listing 9 shows how user greg could set up a directory that all users of the development group could use, along with an example of how user gretchen could create a file in the directory. As created, the file gretchen.txt allows groups members to write to the file, so gretchen uses chmod g-w to disable group write capability.

Listing 9. sgid access mode and directories

[greg@echidna ~]$ mkdir lpi101 [greg@echidna ~]$ chmod g+ws lpi101 [greg@echidna ~]$ ls -ld lpi101 drwxrwsr-x. 2 greg development 4096 Nov 30 13:30 lpi101/ [greg@echidna ~]$ su - gretchen Password: [gretchen@echidna ~]$ touch ~greg/lpi101/gretchen.txt [gretchen@echidna ~]$ ls -l ~greg/lpi101/gretchen.txt -rw-rw-r--. 1 gretchen development 0 Nov 30 14:12 /home/greg/lpi101/gretchen.txt [gretchen@echidna ~]$ chmod g-w ~greg/lpi101/gretchen.txt [gretchen@echidna ~]$ ls -l ~greg/lpi101/gretchen.txt -rw-r--r--. 1 gretchen development 0 Nov 30 14:12 /home/greg/lpi101/gretchen.txt

Any member of the development group can now create files in user greg's lpi101 directory. As Listing 10 shows, other members of the group cannot update the file gretchen.txt. However, they do have write permission to the directory and can therefore delete the file.

Listing 10. sgid access mode and file ownership

[gretchen@echidna ~]$ su - tom Password: [tom@echidna ~]$ echo "something" >> ~greg/lpi101/gretchen.txt -bash: /home/greg/lpi101/gretchen.txt: Permission denied [tom@echidna ~]$ rm ~greg/lpi101/gretchen.txt rm: remove write-protected regular empty file `/home/greg/lpi101/gretchen.txt'? y [tom@echidna ~]$ ls -l ~greg/lpi101/ total 0

The sticky bit
You have just seen how anyone with write permission to a directory can delete files in it. This might be acceptable for a workgroup project, but is not desirable for globally shared file space such as the /tmp directory. Fortunately, there is a solution.
The remaining access mode bit is called the sticky bit. It is represented symbolically by t and numerically as a 1 in the high-order octal digit. It is displayed in a long directory listing in the place of the executable flag for other users (the last character), with the same meaning for upper and lower case as for suid and sgid. If set for a directory, it permits only the owning user or the superuser (root) to delete or unlink a file. Listing 11 shows how user greg could set the sticky bit on his lpi101 directory and also shows that this bit is set for /tmp.

Listing 11. Sticky directories

[greg@echidna ~]$ chmod +t lpi101 [greg@echidna ~]$ ls -ld lpi101 /tmp drwxrwsr-t. 2 greg development 4096 Nov 30 14:16 lpi101 drwxrwxrwt. 24 root root 12288 Nov 30 14:22 /tmp

On a historical note, UNIX® systems used to use the sticky bit on files to hoard executable files in swap space and avoid reloading. Modern Linux kernels ignore the sticky bit if it is set for files.
Access mode summary
Table 3 summarizes the symbolic and octal representation for the three access modes discussed here.

Table 3. Access modes

Access mode	Symbolic	Octal
suid	s with u	4000
sgid	s with g	2000
sticky	t	1000

Combining this with the earlier permission information, you can see that the full octal representation corresponding to greg's lpi101 permissions and access modes of drwxrwsr-t is 3775. While the ls command does not display the octal permissions, you can display them using the find command as shown in Listing 12

Listing 12. Printing symbolic and octal permissions

[greg@echidna ~]$ find . -name lpi101 -printf "%M %m %f\n" drwxrwsr-t 3775 lpi101

Immutable files
The access modes and permissions provide extensive control over who can do what with files and directories. However, they do not prevent things such as inadvertent deletion of files by the root user. Although beyond the scope of LPI Topic 104.5, there are some additional attributes available on various filesystems that provide additional capabilities. One of these is the immutable attribute. If this is set, even root cannot delete the file until the attribute is unset.
Use the lsattr command to see whether the immutable flag (or any other attribute) is set for a file or directory. To make a file immutable, use the chattr command with the -i flag.
Listing 13 shows that user root can create an immutable file but cannot delete it until the immutable flag is removed.

Listing 13. Immutable files

[root@echidna ~]# touch keep.me [root@echidna ~]# chattr +i keep.me [root@echidna ~]# lsattr keep.me ----i--------e- keep.me [root@echidna ~]# rm -f keep.me rm: cannot remove `keep.me': Operation not permitted [root@echidna ~]# chattr -i keep.me [root@echidna ~]# rm -f keep.me

Changing the immutable flag requires root authority, or at least the CAP_LINUX_IMMUTABLE capability. Making files immutable is often done as part of a security or intrusion detection effort. See the capabilities man page (man capabilities) for more information.
The file creation mask
When a new file is created, the creation process specifies the permissions that the new file should have. Often, the mode requested is 0666, which makes the file readable and writable by anyone. Directories usually default to 0777. However, this permissive creation is affected by a umask value, which specifies what permissions a user does not want to grant automatically to newly created files or directories. The system uses the umask value to reduce the originally requested permissions. You can view your umask setting with the umask command, as shown in Listing 14.

Listing 14. Displaying octal umask

[ian@echidna ~]$ umask 0002

Remember that the umask specifies which permissions should not be granted. On Linux systems, where users do not have private groups the umask normally defaults to 0022, which removes group and other write permission from new files. Where users have a private group (as on the Fedora system used in these examples) the umask normally defaults to 0002 which removes the write permission for other users. Use the -S option to display the umask symbolically, in a form that shows which are the permissions that are allowed.
Use the umask command to set a umask as well as display one. So, if you would like to keep your files more private and disallow all group or other access to newly created files, you would use a umask value of 0077. Or set it symbolically using umask u=rwx,g=,o=, as illustrated in Listing 15.

Listing 15. Setting the umask

[ian@echidna ~]$ umask -S u=rwx,g=rwx,o=rx [ian@echidna ~]$ umask u=rwx,g=,o= [ian@echidna ~]$ umask 0077 [ian@echidna ~]$ touch newfile [ian@echidna ~]$ ls -l newfile -rw-------. 1 ian ian 0 Nov 30 15:40 newfile

Setting file owner and group
File group
To change the group of a file, use the chgrp command with a group name and one or more filenames. You may also use the group number if you prefer. An ordinary user must own the file and also be a member of the group to which the file's group is being changed. The root user may change files to any group. Listing 16 shows an example.

Listing 16. Changing group ownership

[ian@echidna ~]$ touch file{1,2} [ian@echidna ~]$ ls -l file* -rw-rw-r--. 1 ian ian 0 Nov 30 15:54 file1 -rw-rw-r--. 1 ian ian 0 Nov 30 15:54 file2 [ian@echidna ~]$ chgrp development file1 [ian@echidna ~]$ chgrp 505 file2 [ian@echidna ~]$ ls -l file* -rw-rw-r--. 1 ian development 0 Nov 30 15:54 file1 -rw-rw-r--. 1 ian development 0 Nov 30 15:54 file2

As with many of the commands covered in this tutorial, chgrp has a -R option to allow changes to be applied recursively to all selected files and subdirectories.
Default group
When you studied Access modes above, you learned how setting the sgid mode on a directory causes new files created in that directory to belong to the group of the directory rather than to the group of the user creating the file.
You may also use the newgrp command to temporarily change your primary group to another group of which you are a member. A new shell will be created, and when you exit the shell, your previous group will be reinstated, as shown in Listing 17.

Listing 17. Using newgrp to temporarily change default group

[ian@echidna ~]$ groups ian development editor [ian@echidna ~]$ newgrp development [ian@echidna ~]$ groups development ian editor [ian@echidna ~]$ touch file3 [ian@echidna ~]$ ls -l file3 -rw-r--r--. 1 ian development 0 Nov 30 16:00 file3 [ian@echidna ~]$ exit [ian@echidna ~]$ groups ian development editor

File owner
The root user can change the ownership of a file using the chown command. In its simplest form, the syntax is like the chgrp command, except that a user name or numeric id is used instead of a group name or id. The file's group may be changed at the same time by adding a colon and a group name or id right after the user name or id. If only a colon is given, then the user's default group is used. Naturally, the -R option will apply the change recursively. Listing 18 shows an example.

Listing 18. Using chown to changing file ownership

[ian@echidna ~]$ touch file4 [ian@echidna ~]$ su - Password: [root@echidna ~]# ls -l ~ian/file4 -rw-rw-r--. 1 ian ian 0 Nov 30 16:04 /home/ian/file4 [root@echidna ~]# chown greg ~ian/file4 [root@echidna ~]# ls -l ~ian/file4 -rw-rw-r--. 1 greg ian 0 Nov 30 16:04 /home/ian/file4 [root@echidna ~]# chown tom:gretchen ~ian/file4 [root@echidna ~]# ls -l ~ian/file4 -rw-rw-r--. 1 tom gretchen 0 Nov 30 16:04 /home/ian/file4 [root@echidna ~]# chown :tom ~ian/file4 [root@echidna ~]# ls -l ~ian/file4 -rw-rw-r--. 1 tom tom 0 Nov 30 16:04 /home/ian/file4

An older form of specifying both user and group used a dot instead of a colon. This is no longer recommended as it may cause confusion when names include a dot.
This completes your introduction to file and directory permissions on Linux.

Resources
Learn

• Use the developerWorks roadmap for LPIC-1 to find the developerWorks articles to help you study for LPIC-1 certification based on the April 2009 objectives.
  
• At the LPIC Program site, find detailed objectives, task lists, and sample questions for the three levels of the Linux Professional Institute's Linux system administration certification. In particular, see their April 2009 objectives for LPI exam 101 and LPI exam 102. Always refer to the LPIC Program site for the latest objectives.
  
• Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for system administrator certification based on earlier LPI exam objectives prior to April 2009.
  
• The Directory listing chapter of the GNU Coreutils manual explains the parts of directory listings.
  
• The Linux Documentation Project has a variety of useful documents, especially its HOWTOs.
  
• In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
  
• Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
  
• Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
  
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
  
• Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.
• http://www.ibm.com/developerworks/linux/library/l-lpic1-v3-104-5/index.html

There is no "CHOWN 777". CHOWN is "change owner".

http://www.oreillynet.com/linux/cmd/cmd.csp?path=c/chown

CHOWN new-owner filename changes the ownership of a file to another user of the file system (in this case either yourself or apache), and this command is only available to your server's admins. So, they essentially offered you to change the owner of the files to yourself or to apache. Your options are:

(a) If the owner of drupal's files directory is apache. then the directory can be set to 755 and apache still can read it (because if apache owns it then apache is the first digit of 755).

So, no need for 777, and the other users of your server (or even you) won't be able to write to this directory directly (only through a php script like Drupal, because php scripts write as user apache).

The downside is inconvenience: you won't be able to write into this 755 directory yourself, or to delete it, or to chmod it, except if you do it through a php script or if you ask your host to do what you want every time.

(b) If the owner is yourself you have full control of the file to do whatever you want, but then apache can write only if you CHMOD it to 777.

Your choice. I would take (b).


Although rusty has clarified all the tech things related to chown and chmod, let me put additional help - if it is.

First, you need to to know what chown is and what chmod is (perhaps you already know it as well)

chown, in simple words relates to "Who owns the file / directory etc." i.e. CHange OWNership ... right

chmod, on the other hand refers to "Who all can do what all things" - i.e. what owner can do, what his associates (in the group) can do and finally, what all everybody else can do...

Right... Now, what happens is this - You say that you own the file, directory etc... Correct, you surely do. However when the program runs, (the web server executes / parses the drupal or any other script) , the important point to note is - that it is not YOU who is doing the operations (reading / writing etc.) it the the web server (maybe Apache) ... so here is the difference. The files appears to be owned by you, (and they are) but they need to WORKED upon by someone else (apache) who is neither you, nor your group member. The necessary condition (usually) is that WEB SERVER NEEDS TO WRITE, - it's up to you to decide how you permit it.

So, what is the solution? Either you make those directories / files owned by Apache (not you) with your own rights limited to what would be the rights of the world (all users) - i.e. all other users including yourself have a limited right of viewing . chown to web server user name

Or the other alternative is, let yourself be the owner and allow all users do anything (that includes web server too) - chmod 777

Thus, there is nothing like chown 777 (unless 777 refers to user id ;)

So, either of these would let web server write to those directories, where it wants to. The dilemma has to be solved by you - the first approach is a bit more secure but perhaps less inconvenient (you may not create files, yourself for any reason, whatever it may be) and the second solution is more convenient, allowing complete freedom to all, albeit with security risk.

If the writable directory contains, temp file and not very vulnerable data, perhaps I'd go with second option (at least for the initial period)

By Van Emery
Table of Contents

* Introduction
* Assumptions
* Getting Started
* Using ACLs
* More setfacl Details and Examples
* Example Scenario
* The Default ACL
* Using cp and mv with ACLs
* Copying ACLs
* Archive and Restore Files with ACLs
* XFS Notes
* Final Notes
* Additional Resources


Introduction

What are ACLs and why would you want to use them?

ACLs are Access Control Lists for files and directories. They are based on the IEEE's POSIX 1003.1e draft 17, also known simply as POSIX.1e. ACLs are an addition to the standard Unix file permissions (r,w,x,-) for User, Group, and Other. ACLs give users and administrators flexibility and fine-grained control over who can read, write, and execute files. This can all be done without adding mysterious groups and pestering the system administrator.

Commercial Unix operating systems (except SCO) have all had ACL functionality for quite awhile. Microsoft's NTFS also has similar capabilities. FreeBSD 5.x supports POSIX.1e ACLs as well. The new Linux 2.6 kernel supports ACLs for EXT2, EXT3, XFS, JFS, and ReiserFS.

Fedora Core 2, Red Hat's first distribution with a 2.6 kernel, is a good vehicle for taking Linux ACLs for a test drive. This document is a basic HOWTO/tutorial on using ACLs with Fedora.
Assumptions

* You are using Fedora Core 2
* You have another partition besides /, /boot, and swap defined, or some unpartitioned free space on one of your disks
* You are using the EXT2, EXT3, or XFS filesystems
* You can login as root

If you have no free space on the disk, and all of your files and binaries are located in the root ( / ) partition, then you may not want to experiment with ACLs.

Note: Both JFS and ReiserFS can support ACLs under Linux, but Fedora Core 2 does not appear to support it. ReiserFS cannot be mounted with the "acl" option, and jfs_mkfs appears to be seriously broken. Therefore, this HOWTO will be limited to EXT2, EXT3, and XFS.
Getting Started

Assuming you have an EXT2 or EXT3 partition that you are willing to use for testing, we can get started. On my test machine, I have the following available partitions:

* /dev/hda5 /home (ext3)
* /dev/hda9 /XFS (xfs)

For the examples in this HOWTO, I will be using the home directory of user "tristan", which is /home/tristan. Note that this directory belongs to a separate Linux partition, not the the root ( / ) partition. If you have some extra unpartitioned space on one of your disks, this would be a good time to create a test partition. You can do this with the fdisk command, then you can format it with the mke2fs command. Make sure you read up on all the required steps before you do this, otherwise you can nuke your system, disk, or data!

If you did not install Fedora Core 2 with the "XFS" option, but you want to try ACLs on XFS, take a look at the XFS Notes section.

You will need to unmount the partitions of your choice, and then remount them with the "acl" option. First, I made a copy of my /etc/fstab file:

[root@fc2 root]# cp -v /etc/fstab /etc/fstab.org
`/etc/fstab' -> `/etc/fstab.org'

Then, I made the following modifications in red to the /etc/fstab config file. For clarity, I am only including hard disk entries:

LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
LABEL=/home /home ext3 rw,acl 1 2
LABEL=/tmp /tmp ext3 defaults 1 2
LABEL=/usr /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
/dev/hda8 swap swap defaults 0 0
/dev/hdd1 /Data ext3 ro,noatime 1 2
LABEL=/XFS /XFS xfs rw,noatime 0 2

Now, you will need to remount the /home partition with the "acl" option. The easiest way to do this is with the "remount" option, since it will work even while the partition is in use:

[root@fc2 root]# mount -v -o remount /home
/dev/hda5 on /home type ext3 (rw,acl)

Another way to remount the partition with the "acl" option is to make sure that nobody else is on the sytem and the /home partition is not in use, then unmount, then mount the partition:

[root@fc2 root]# umount /home
[root@fc2 root]# mount /home

[root@fc2 root]# mount -l
/dev/hda2 on / type ext3 (rw) [/]
/dev/hda1 on /boot type ext3 (rw) [/boot]
/dev/hda5 on /home type ext3 (rw,acl) [/home]
/dev/hda7 on /tmp type ext3 (rw) [/tmp]
/dev/hda3 on /usr type ext3 (rw) [/usr]
/dev/hda6 on /var type ext3 (rw) [/var]
/dev/hdd1 on /Data type ext3 (ro,noatime) []
/dev/hda9 on /XFS type xfs (rw,noatime) [/XFS]

If you had trouble unmounting your target partitions, you may need to drop to single user mode with the init 1 command. This should allow you to unmount the filesystems. After that, you can remount the filesystems and issue an init 3 or init 5 command to put you back into your regular operating environment.
Using ACLs

Now, we can actually start using ACLs. The basic commands that we are interested in are:

* getfacl
* setfacl

We will first look at the getfacl command. The owner of the directory we will be working with is "tristan", and the guest user will be "axel" and the guest group will be "lensmen". First, create a test file, then look at the permissions and the ACL:

[tristan@fc2 tristan]$ cd /home/tristan
[tristan@fc2 tristan]$ cp /etc/services pizza

[tristan@fc2 tristan]$ ls -l pizza
-rw-r--r-- 1 tristan tristan 19936 May 28 16:59 pizza

[tristan@fc2 tristan]$ getfacl pizza
# file: pizza
# owner: tristan
# group: tristan
user::rw-
group::r--
other::r--

So far, there is nothing very exciting to see. Now, let's change the ACL so that user "axel" can read and write to the file:

[tristan@fc2 tristan]$ setfacl -m u:axel:rw- pizza
[tristan@fc2 tristan]$ getfacl pizza
# file: pizza
# owner: tristan
# group: tristan
user::rw-
user:axel:rw-
group::r--
mask::rw-
other::r--

[tristan@fc2 tristan]$ ls -l pizza
-rw-rw-r--+ 1 tristan tristan 19936 May 28 16:59 pizza

You will notice that there is now an extra user entry in the ACL, and there is a "+" next to the file in the output from the ls command. The "+" indicates that an ACL has been applied to the file or directory. Now, let's add a group ("lensmen") and another user ("tippy") to the ACL for pizza:

[root@fc2 tristan]# setfacl -m u:tippy:r--,g:lensmen:r-- pizza

[root@fc2 tristan]# getfacl pizza
# file: pizza
# owner: tristan
# group: tristan
user::rw-
user:axel:rw-
user:tippy:r--
group::r--
group:lensmen:r--
mask::rw-
other::r--

Hmmm...what's the mask entry? This is the effective rights mask. This entry limits the effective rights granted to all ACL groups and ACL users. The traditional Unix User, Group, and Other entries are not affected. If the mask is more restrictive than the ACL permissions that you grant, then the mask takes precedence. For example, let's change the mask to "r--" and give user "tippy" and group "lensmen" the permissions rwx, and see what happens:

[tristan@fc2 tristan]$ setfacl -m u:tippy:rwx,g:lensmen:rwx pizza

[tristan@fc2 tristan]$ setfacl -m mask::r-- pizza

[tristan@fc2 tristan]$ getfacl --omit-header pizza
user::rw-
user:axel:rw- #effective:r--
user:tippy:rwx #effective:r--
group::r--
group:lensmen:rwx #effective:r--
mask::r--
other::r--

The ACL now shows an "effective" rights mask. Even though "tippy" has been given rwx permissions, he actually only has r-- permissions because of the mask.

In most cases, I want the effective mask to allow whatever permissions I granted to named users and groups, so my mask will be rw- or rwx. I will reset it like this:

[tristan@fc2 tristan]$ setfacl -m m::rw- pizza

[tristan@fc2 tristan]$ getfacl --omit pizza
user::rw-
user:axel:rw-
user:tippy:rw-
group::r--
group:lensmen:rwx #effective:rw-
mask::rw-
other::r--

What about using the setfacl command to change normal User, Group, and Other permissions? No problem! This can be used instead of chmod:

[tristan@fc2 tristan]$ setfacl -m u::rwx,g::rwx,o:rwx pizza

[tristan@fc2 tristan]$ ls -l pizza
-rwxrwxrwx+ 1 tristan tristan 19965 May 29 09:31 pizza

[tristan@fc2 tristan]$ getfacl --omit pizza
user::rwx
user:axel:rw-
user:tippy:rw-
group::rwx
group:lensmen:rwx
mask::rwx
other::rwx

Note that the mask changed! Whenever you change the permissions of a user or a group with setfacl, the mask is changed to match. Therefore, if you want a restrictive mask, it must be applied after the user and group permissions are modified.

Another thing to keep in mind is that the chmod command does not alter the file's ACL...the ACL information will remain intact, except that the mask entry can change as described above.
More setfacl Details and Examples

The setfacl command has many options. In this section, we will look at some of the more useful ones.
Remove Specific Entries from an ACL

You can remove specific ACL entries with the -x option. In this example, we will remove the entry for user "tippy" and user "axel" but leave the other entries alone:

[tristan@fc2 tristan]$ getfacl --omit pizza
user::rwx
user:axel:rw-
user:tippy:rw-
group::rwx
group:lensmen:rwx
mask::rwx
other::rwx

[tristan@fc2 tristan]$ setfacl -x u:tippy,u:axel pizza

[tristan@fc2 tristan]$ getfacl --omit pizza
user::rwx
group::rwx
group:lensmen:rwx
mask::rwx
other::rwx

Error:

drwxr-srwx+ 2 smbwi webdev 4.0K Nov 6 12:19 news
drwxr-srwx+ 2 smbwi webdev 20K Nov 6 12:20 items
drwxr-srwx+ 2 smbwi webdev 4.0K Nov 6 12:20 faq

Soluton:

Remove Entire ACL

To completely remove an ACL from a file or directory:

[tristan@fc2 tristan]$ setfacl -b pizza

You can also use:

[tristan@fc2 tristan]$ setfacl --remove-all pizza

Using the --set Option

If you want to explicitly set all of the file permissions on a file or a group of files, you must use the --set option. This is different from the -m option, which only modifies the existing ACL. The --set option replaces all permissions and ACLs with the new values. When you use the --set option, all of the User, Group, and Other permissions must be defined. Here is an example:

[tristan@fc2 tristan]$ setfacl --set u::rw,g::rw,o::-,u:tippy:r pizza

[tristan@fc2 tristan]$ getfacl --omit pizza
user::rw-
user:tippy:r--
group::rw-
mask::rw-
other::---

Using setfacl Recursively

If you want to apply ACLs to an entire directory and all of its subdirectories, use the -R option. Given the directory hierarchy /home/tristan/Level1/Level2/Level3/Level4, the following command will add an ACL entry for group "lensmen" to all of the Level* directories and their contents:

[tristan@fc2 tristan]$ setfacl -R -m g:lensmen:r-x /home/tristan/Level1

Using ACL Entries from a File:

What if you have a lengthy ACL that needs to be used frequently? Rather than typing it over and over again on the command line, you can save the ACL as a text file and use it to apply ACLs to other files. For example, we will create the ACL config file /home/tristan/myacl:

user:axel:rw-
user:tippy:rw-
group:lensmen:r--
group:marty:r--
group:fafnir:r--
mask::rw-
other::---

Now, we can easily apply these ACL modifications to files:

[tristan@fc2 tristan]$ setfacl -M myacl test*

[tristan@fc2 tristan]$ ls -l test*
-rw-rw----+ 1 tristan tristan 168 May 30 09:41 test1
-rw-rw----+ 1 tristan tristan 168 May 30 09:42 test2
-rw-rw----+ 1 tristan tristan 168 May 30 09:42 test3

[tristan@fc2 tristan]$ getfacl test1
# file: test1
# owner: tristan
# group: tristan
user::rw-
user:axel:rw-
user:tippy:rw-
group::rw-
group:marty:r--
group:lensmen:r--
group:fafnir:r--
mask::rw-
other::---

Note on UID, GID, and Permissions

When you are using setfacl, you can use numeric UIDs and GIDs instead of the actual names. The UIDs and GIDs do not have to exist yet. If you use names, then they must exist or you will get an error. You can use the

getfacl --numeric filename

command to view the numeric values.

Also, when you are specifying permissions, you can use octal permissions (0-7) instead of (r,w,x,-).
Example Scenario

Now that we have seen basic command usage, let's use a practical example to learn some more about ACLs. Tippy is working with Tristan on a project. He needs to be able to read, write, create, and delete files related to the project, which are located in Tristan's home directory. Tristan wants to do this without bothering the system administrator with requests for new groups and group membership changes. When the project is over, Tristan will remove the permissions for user "tippy" without bothering the sysadmin.

All of the project files are located in /home/tristan/Project. Here is how Tristan will handle the situation:

[tristan@fc2 tristan]$ setfacl -m user:tippy:--x /home/tristan
[tristan@fc2 tristan]$ getfacl /home/tristan
getfacl: Removing leading '/' from absolute path names
# file: home/tristan
# owner: tristan
# group: tristan
user::rwx
user:tippy:--x
group::---
mask::--x
other::---

[tristan@fc2 tristan]$ setfacl -R -m u:tippy:rwx,o::--- Project
[tristan@fc2 tristan]$ getfacl Project
# file: Project
# owner: tristan
# group: tristan
user::rwx
user:tippy:rwx
group::rwx
mask::rwx
other::---

[tristan@fc2 tristan]$ cd Project
[tristan@fc2 Project]$ ls -l
total 1560
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so.2
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so.2.2
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so.3
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so.3.2
[tristan@fc2 Project]$ getfacl --omit libkrb5.so
user::rwx
user:tippy:rwx
group::r-x
mask::rwx
other::---

Now, Tippy can access the /home/tristan/Project directory. He can read, modify, add, and delete files. However, he cannot delete the Project directory, nor can he view any other files in Tristan's home directory. This is good, because Tippy likes to test his limits. Let's see what he can and can't do:

[tippy@fc2 tippy]$ cd /home/tristan
[tippy@fc2 tristan]$ ls
ls: .: Permission denied
[tippy@fc2 tristan]$ rm -rf Project
rm: cannot remove `Project': Permission denied
[tippy@fc2 tristan]$ cd Project
[tippy@fc2 Project]$ ls -l
total 1560
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so.2
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so.2.2
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so.3
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so.3.2
[tippy@fc2 Project]$ touch status-report.txt

[tippy@fc2 Project]$ date >> libkrb5.so.3
[tippy@fc2 Project]$ rm libkrb5.so.3
[tippy@fc2 Project]$ ls -l
total 1136
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so.2
-rwxrwx---+ 1 tristan tristan 86532 May 29 14:02 libgssapi_krb5.so.2.2
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so
-rwxrwx---+ 1 tristan tristan 423572 May 29 14:02 libkrb5.so.3.2
-rw-rw-r-- 1 tippy tippy 0 May 29 16:06 status-report.txt

Now, after the project is complete, it is a simple matter for user Tristan to revoke Tippy's access to /home/tristan:

[tristan@fc2 tristan]$ setfacl -x u:tippy: /home/tristan
[tristan@fc2 tristan]$ getfacl /home/tristan
getfacl: Removing leading '/' from absolute path names
# file: home/tristan
# owner: tristan
# group: tristan
user::rwx
group::---
mask::---
other::---

If user "tippy" decides to snoop around in /home/tristan/Project again, he will not be able to:

[tippy@fc2 tippy]$ cd /home/tristan
-bash: cd: /home/tristan: Permission denied
[tippy@fc2 tippy]$ ls /home/tristan/Project
ls: /home/tristan/Project: Permission denied

Note that this entire example was done without having to involve the system administrator!
The Default ACL

Up until now, we have been looking at the access ACL. There is also another type of ACL, called the default ACL. The default ACL is only applied to directories, and it defines the permissions that a newly created file or directory inherits from its parent directory.

When you create a new directory inside a directory that already has a default ACL, the new directory inherits the default ACL both as its access ACL and its default ACL.

Here is an example of defining a default ACL for a directory, and what happens when files and directories are created underneath that directory:

[tristan@fc2 tristan]$ mkdir Plato

[tristan@fc2 tristan]$ setfacl --set u::rwx,g::r-x,o::- Plato

[tristan@fc2 tristan]$ setfacl -d --set u::rwx,u:tippy:rwx,u:axel:rx,g::rx,g:lensmen:rx,o::- Plato
[tristan@fc2 tristan]$ getfacl Plato
# file: Plato
# owner: tristan
# group: tristan
user::rwx
group::r-x
other::---
default:user::rwx
default:user:axel:r-x
default:user:tippy:rwx
default:group::r-x
default:group:lensmen:r-x
default:mask::rwx
default:other::---

[tristan@fc2 tristan]$ cd Plato
[tristan@fc2 Plato]$ touch guitar
[tristan@fc2 Plato]$ getfacl guitar
# file: guitar
# owner: tristan
# group: tristan
user::rw-
user:axel:r-x #effective:r--
user:tippy:rwx #effective:rw-
group::r-x #effective:r--
group:lensmen:r-x #effective:r--
mask::rw-
other::---

[tristan@fc2 Plato]$ mkdir Zep
[tristan@fc2 Plato]$ getfacl Zep
# file: Zep
# owner: tristan
# group: tristan
user::rwx
user:axel:r-x
user:tippy:rwx
group::r-x
group:lensmen:r-x
mask::rwx
other::---
default:user::rwx
default:user:axel:r-x
default:user:tippy:rwx
default:group::r-x
default:group:lensmen:r-x
default:mask::rwx
default:other::---

[tristan@fc2 Plato]$ cd Zep
[tristan@fc2 Zep]$ touch airship
[tristan@fc2 Zep]$ getfacl airship
# file: airship
# owner: tristan
# group: tristan
user::rw-
user:axel:r-x #effective:r--
user:tippy:rwx #effective:rw-
group::r-x #effective:r--
group:lensmen:r-x #effective:r--
mask::rw-
other::---

The umask has no effect if a default ACL exists. In the following example, the umask is honored when a file is created in the /home/tristan directory, which has no default ACL. When a file is created under /home/tristan/Plato, which has a default ACL, you can see that the umask is ignored:

[tristan@fc2 tristan]$ umask ugo=
[tristan@fc2 tristan]$ umask
0777
[tristan@fc2 tristan]$ touch button
[tristan@fc2 tristan]$ ls -l button
---------- 1 tristan tristan 0 Jun 1 00:47 button

[tristan@fc2 tristan]$ cd Plato
[tristan@fc2 Plato]$ touch switch
[tristan@fc2 Plato]$ ls -l switch
-rw-rw----+ 1 tristan tristan 0 Jun 1 00:47 switch

You can also modify and create default ACLs with another syntax, prefixing the u, g, or o entries with a "d" :

[tristan@fc2 tristan]$ setfacl -m d:u:axel:rwx,d:g:lensmen:rwx Plato
[tristan@fc2 tristan]$ getfacl Plato
# file: Plato
# owner: tristan
# group: tristan
user::rwx
group::r-x
other::---
default:user::rwx
default:user:axel:rwx
default:user:tippy:rwx
default:group::r-x
default:group:lensmen:rwx
default:mask::rwx
default:other::---

Using cp and mv with ACLs

Three major file utilities, ls, cp, and mv have been updated to handle ACLs. The mv command will always preserve ACLs if it is possible. If it is not possible, it will issue a warning. The cp command will only preserve ACLs if used with the -p or -a options.

In both cases, if you are trying to copy/move from a filesystem that supports ACLs to a filesystem that does not, only the standard Unix permissions will be retained. In the example below, you can see that using the cp -p command within the ACL-enabled /home filesystem worked, and using the same command to copy the file to the /root directory (which is not ACL-enabled) resulted in an error message. As root, do the following:

[root@fc2 root]# cd /home/tristan
[root@fc2 tristan]# mkdir ACL
[root@fc2 tristan]# cp -p pizza ACL/pizza
[root@fc2 tristan]# ls -l ACL/pizza
-rw-rwx---+ 1 tristan tristan 19965 May 29 09:31 ACL/pizza

[root@fc2 tristan]# cp -p pizza /root
cp: preserving permissions for `/root/pizza': Operation not supported
[root@fc2 tristan]# ls -l /root/pizza
-rw-rwx--- 1 tristan tristan 19965 May 29 09:31 /root/pizza

Copying ACLs

If you already have a file with a complex ACL, you can easily copy that ACL to other files by piping the output of a getfacl command into the setfacl command. Here is an example of copying the ACL from bingo.txt to all of the files starting with "test":

[tristan@fc2 Compaq]$ ls -l
total 4
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:52 bingo.txt
-rw-rw---- 1 tristan tristan 0 Jun 2 09:53 testa1
-rw-rw---- 1 tristan tristan 0 Jun 2 09:53 testa2
-rw-rw---- 1 tristan tristan 0 Jun 2 09:55 testa3
-rw-rw---- 1 tristan tristan 0 Jun 2 09:53 testa4
-rw-rw---- 1 tristan tristan 0 Jun 2 09:55 testa5

[tristan@fc2 Compaq]$ getfacl bingo.txt | setfacl --set-file=- test*

[tristan@fc2 Compaq]$ ls -l
total 24
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:52 bingo.txt
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:53 testa1
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:53 testa2
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:55 testa3
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:53 testa4
-rw-rw----+ 1 tristan tristan 0 Jun 2 09:55 testa5

[tristan@fc2 Compaq]$ getfacl --omit testa5
user::rw-
user:axel:rw-
user:tippy:rw-
group::rw-
group:marty:r--
group:lensmen:r--
group:fafnir:r--
mask::rw-
other::---

You can also archive all of the ACLs from an entire directory tree, then restore them later. You might want to do this if you are recovering files from backup media that does not support ACLs, like CD-ROM. Here is an example of archiving/saving all of the ACLs in the /home/tristan/Tree directory tree, and restoring them.

There are 898 files in this tree:

[tristan@fc2 tristan]$ du -h Tree
9.5M Tree/A/B/C/D
19M Tree/A/B/C
29M Tree/A/B
38M Tree/A
9.5M Tree/AA/BB/CC/DD
19M Tree/AA/BB/CC
29M Tree/AA/BB
38M Tree/AA
86M Tree

Now, let's archive the ACLs into a file in our home directory:

[tristan@fc2 tristan]$ getfacl -R Tree > Tree.facl
[tristan@fc2 tristan]$ ls -l Tree.facl
-rw-rw-r-- 1 tristan tristan 120550 Jun 2 12:08 Tree.facl

Now, we will simulate restoring the files from CD without ACLs by stripping all of the ACLs off:

[tristan@fc2 tristan]$ setfacl -R -b Tree

Now we can restore all of the ACL entries with one command:

[tristan@fc2 tristan]$ setfacl --restore Tree.facl

Archive and Restore Files with ACLs

What if you want to archive/backup files or directories with ACLs? Besides cp, what is there? Unfortunately, tar, cpio, pax, and dump will not save and restore ACL information. You can use the setfacl --restore mechanism in conjunction with a standard archiving/ backup system, but that is far from ideal. The answer is star, a TAR-like utility that is included in the Fedora Core 2 distribution.

Quotes from Star's author:

* Star is the fastest known implementation of a tar archiver.
* Star is even faster than ufsdump in nearly all cases.

Sounds interesting, doesn't it?

We can archive the entire /home/tristan/Tree directory tree from our previous example. We have to use the acl and -Hexustar options in order to archive and restore the ACL data. Here we go:

[tristan@fc2 /]$ cd /home/tristan

[tristan@fc2 tristan]$ star -Hexustar -acl -c f=Tree.star Tree
star: 8201 blocks + 0 bytes (total of 83978240 bytes = 82010.00k).

Now we will simulate losing our files and restoring them from a Star archive:

[tristan@fc2 tristan]$ rm -rf Tree

[tristan@fc2 tristan]$ star -acl -x f=Tree.star
star: 8201 blocks + 0 bytes (total of 83978240 bytes = 82010.00k).

When you check out the /home/tristan/Tree directory tree, you will find that it has been restored along with all the ACLs!
rdiff-backup

If you want to use a disk-to-disk backup instead of a tape archiver, consider using rdiff-backup. The stable branch now supports ACLs.

XFS Notes - Setting Up an XFS Filesystem with ACLs

XFS natively supports POSIX.1e ACLs. Unless you installed Fedora Core 2 with the XFS option, you will need to install the XFS RPM packages in order to use XFS. They are located on FC-2 ISO disk #4, in the Fedora/RPMS directory. You will need to install the following packages:

* xfsprogs-2.6.13-1.i386.rpm
* xfsprogs-devel-2.6.13-1.i386.rpm

Use the rpm -ivh xfsprogs*rpm command and you will soon be ready to go.

You will need a spare partition for your XFS filesystem. In my case, I created a spare partition as /dev/hda9. You must now create an XFS filesystem:

[root@fc2 root]# mkfs.xfs -i size=512 -f -L "/XFS" /dev/hda9
meta-data=/dev/hda9 isize=512 agcount=8, agsize=61046 blks
= sectsz=512
data = bsize=4096 blocks=488368, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=2560, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0

The -i option is used to specify the size of the inodes. 256 is the default, but 512 bytes per inode significantly increases the speed of ACL lookups.

Now, create a directory to act as the mountpoint:

[root@fc2 root]# mkdir /XFS

Now, we have to actually mount the new filesystem. Unlike EXT2 and EXT3, no "acl" option is necessary. XFS assumes that you want ACLs. Example:

[root@fc2 root]# mount -v -t xfs /dev/hda9 /XFS
/dev/hda9 on /XFS type xfs (rw)

[root@fc2 root]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 4.2G 197M 3.8G 5% /
/dev/hda1 97M 5.9M 86M 7% /boot
/dev/hda5 9.7G 128M 9.0G 2% /home
/dev/hda7 985M 17M 919M 2% /tmp
/dev/hda3 15G 3.2G 11G 23% /usr
/dev/hda6 4.9G 184M 4.4G 4% /var
/dev/hdd1 29G 11G 17G 38% /Data
/dev/hda9 1.9G 160K 1.9G 1% /XFS

Alternatively, you could have used the mount command with the disk label "/XFS" that was added when you created the XFS filesystem. Example:

[root@fc2 root]# mount -v -t xfs -L "/XFS" /XFS
mount: mounting /dev/hda9
/dev/hda9 on /XFS type xfs (rw)

The last step is to add an entry to /etc/fstab so that the filesystem/partition will be mounted automatically during system boot. Here is a sample entry:

LABEL=/XFS /XFS xfs rw,noatime 0 2

You can now start using the filesystem with ACLs.
Final Notes

There are limits to how many ACL entries can be applied to each file or directory. The number is filesystem dependent. EXT2 and EXT3 can have up to 32 entries, and XFS can have up to 25. Reiser and JFS can have over 8,000.

Enabling and using ACLs on a filesystem can reduce performance. It does not make sense to use ACLs for the root partition ( / ), /boot, /usr, /var, etc. I can see ACLs being very useful in /home and other user data partitions.

The only way to get familiar with Linux ACLs is to practice using them. Have fun with it!
Additional Resources

* Andreas Grünbacher's "POSIX Access Control Lists on Linux" whitepaper (local copy)
* Excellent article on Linux ACLs by Carla Schroeder
* Linux ACL Homepage
* rdiff-backup page
* man getfacl
* man setfacl
* man acl
* man star
* /usr/share/doc/star-1.5a25 documentation
* Star ACL README file


Last updated: 2005-09-22


Reference: http://www.vanemery.com/Linux/ACL/linux-acl.html

I needed to get a list of all the subdirectories that were owner by some other user than root under /var and their permissions/owner with full paths. My first thought was to use ls and something like this:
ls -dlR */
drwxr-xr-x 2 root root 4096 2009-06-05 06:25 backups/
drwxr-xr-x 8 root root 4096 2009-05-11 06:02 cache/
drwxr-xr-x 2 root root 4096 2009-05-06 04:49 ec2/
drwxr-xr-x 25 root root 4096 2009-05-25 14:55 lib/
...
will show the subdirectories just as I needed but only at one level. Using */*/ would show the next level, etc. This obviously is not a solution and unfortunately I had found no other way to do this with ls. Using:
ls -alR | grep ^d
drwxr-xr-x 15 root root 4096 2009-05-11 06:02 .
drwxr-xr-x 22 root root 4096 2009-06-03 15:02 ..
drwxr-xr-x 2 root root 4096 2009-06-05 06:25 backups
drwxr-xr-x 8 root root 4096 2009-05-11 06:02 cache
drwxr-xr-x 2 root root 4096 2009-05-06 04:49 ec2
drwxr-xr-x 25 root root 4096 2009-05-25 14:55 lib
....
works somehow, but since I don’t have the full paths this is useless.

Maybe this can be done with ls, but since I have not found a way to do this, I turned to find. Find allows me very simple to get the list of subdirectories with their full paths:
find /var -type d
/var
/var/backups
/var/lib
/var/lib/ucf
/var/lib/ucf/cache
/var/lib/vim
/var/lib/vim/addons
/var/lib/php5
/var/lib/iptraf
/var/lib/mysql-cluster
/var/lib/collectd
...
and to get also the owner/permissions we can get help from ls:
ls -dl `find /var -type d`
drwxr-xr-x 15 root root 4096 2009-05-11 06:02 /var
drwxr-xr-x 2 root root 4096 2009-06-05 06:25 /var/backups
drwxr-xr-x 8 root root 4096 2009-05-11 06:02 /var/cache
drwxr-xr-x 3 www-data www-data 4096 2009-05-11 06:02 /var/cache/apache2
drwxr-xr-x 2 www-data www-data 4096 2008-09-08 05:08 /var/cache/apache2/mod_disk_cache
drwxr-xr-x 3 root root 4096 2009-06-03 09:32 /var/cache/apt
drwxr-xr-x 3 root root 4096 2009-06-03 09:32 /var/cache/apt/archives
drwxr-xr-x 2 root root 4096 2009-06-03 09:32 /var/cache/apt/archives/partial
drwxr-xr-x 2 root root 4096 2009-06-05 06:25 /var/cache/apt-show-versions
drwxr-xr-x 2 root root 4096 2009-06-03 09:32 /var/cache/debconf
drwxr-xr-x 2 root root 4096 2009-06-05 06:25 /var/cache/locate
drwxr-sr-x 42 man root 4096 2009-06-05 06:25 /var/cache/man
...

And finally the oneliner that gives us all the folders that are owned by some other user as root:
ls -dl `find /var -type d` | grep -v root
drwxr-xr-x 3 www-data www-data 4096 2009-05-11 06:02 /var/cache/apache2
drwxr-xr-x 2 www-data www-data 4096 2008-09-08 05:08 /var/cache/apache2/mod_disk_cache
drwxr-s--- 2 mysql adm 4096 2009-06-05 06:25 /var/log/mysql
drwxr-sr-x 2 news news 4096 2009-05-06 04:49 /var/log/news

time for awk now ;)

Update: as per the comment bellow from chlovechek a much cleaner solution is:
find /var ! -user root -type d -ls

Reference: http://www.ducea.com/2009/06/05/linux-tips-get-the-list-of-subdirectories-with-their-owner-permissions-and-full-paths/

#!/bin/bash
IFS="
"

find / -user username >> /tmp.out

for i in `cat /tmp.out`; do
chown username "$i"
done
rm /tmp.out

exit

#find . -user username -exec chown otheruser {} \;
# find . -group apache -exec chgrp root {} \;

#find . -user username -exec chown otheruser {} \;
# find . -perm 775 -type d -exec chmod 775 {} \;
# find . -perm 644 -type f -exec chmod 664 {} \;

This sample chapter explains common Linux partitioning options so you can determine which is best for you. It also discusses how to use access control lists to limit access to filesystems as well as how to enforce disk usage limits known as quotas
Using Access Control Lists

On an ext3 filesystem, read, write, and execute permissions can be set for the owner of the file, the group associated with the file, and for everyone else who has access to the filesystem. These files are visible with the ls -l command. Refer to Chapter 4, “Understanding Linux Concepts,” for information on reading standard file permissions.

In most cases, these standard file permissions along with restricted access to mounting filesystems are all that an administrator needs to grant file privileges to users and to prevent unauthorized users from accessing important files. However, when these basic file permissions are not enough, access control lists, or ACLs, can be used on an ext3 filesystem.

ACLs expand the basic read, write, and execute permissions to more categories of users and groups. In addition to permissions for the owner and group for the file, ACLs allow for permissions to be set for any user, any user group, and the group of all users not in the group for the user. An effective rights mask, which is explained later, can also be set to restrict permissions.

To use ACLs on the filesystem, the acl package must be installed. If it is not already installed, install it via Red Hat Network as discussed in Chapter 3.
Enabling ACLs

To use ACLs, they must be enabled when an ext3 filesystem is mounted. This is most commonly enabled as an option in /etc/fstab. For example:

LABEL=/share /share ext3 acl 1 2

If the filesystem can be unmounted and remounted while the system is still running, modify /etc/fstab for the filesystem, unmount it, and remount it so the changes to /etc/fstab take effect. Otherwise, the system must be rebooted to enable ACLs on the desired filesystems.

If you are mounting the filesystem via the mount command instead, use the -o acl option when mounting:

mount -t ext3 -o acl

Setting and Modifying ACLs

There are four categories of ACLs per file: for an individual user, for a user group, via the effective rights mask, and for users not in the user group associated with the file. To view the existing ACLs for a file, execute the following:

getfacl

If ACLs are enabled, the output should look similar to Listing 7.10.
Listing 7.10. Viewing ACLs

# file: testfile
# owner: tfox
# group: tfox
user::rwx
group::r-x
mask::rwx
other::r-x

To set or modify existing ACLs, use the following syntax:

setfacl -m

Other useful options include --test to show the results of the command but not change the ACL and -R to apply the rules recursively.

Replace with one or more space-separated file or directory names. Rules can be set for four different rule types. Replace with one or more of the following, and replace in these rules with one or more of r, w, and x (which stand for read, write, and execute):

* For an individual user:

u::

* For a specific user group:

g::

* For users not in the user group associated with the file:

o:

* Via the effective rights mask:

m:

The first three rule types (individual user, user group, or users not in the user group for the file) are pretty self-explanatory. They allow you to give read, write, or execute permissions to users in these three categories. A user or group ID may be used, or the actual username or group name.

CAUTION

If the actual username or group name is used to set an ACL, the UID or GID for it are still used to store the ACL. If the UID or GID for a user or group name changes, the ACLs are not changed to reflect the new UID or GID.

But, what is the effective rights mask? The effective rights mask restricts the ACL permission set allowed for users or groups other than the owner of the file. The standard file permissions are not affected by the mask, just the permissions granted by using ACLs. In other words, if the permission (read, write, or execute) is not in the effective rights mask, it appears in the ACLs retrieved with the getfacl command, but the permission is ignored. Listing 7.11 shows an example of this where the effective rights mask is set to read-only, meaning the read-write permissions for user brent and the group associated with the file are effectively read-only. Notice the comment to the right of the ACLs affected by the effective rights mask.
Listing 7.11. Effective Rights Mask

# file: testfile
# owner: tammy
# group: tammy
user::rw-
user:brent:rw- #effective:r--
group::rw- #effective:r--
mask::r--
other::rw-

The effective rights mask must be set after the ACL rule types. When an ACL for an individual user (other than the owner of the file) or a user group is added, the effective rights mask is automatically recalculated as the union of all the permissions for all users other than the owner and all groups including the group associated with the file. So, to make sure the effective rights mask is not modified after setting it, set it after all other ACL permissions.

If the ACL for one of these rule types already exists for the file or directory, the existing ACL for the rule type is replaced, not added to. For example, if user 605 already has read and execute permissions to the file, after the u:605:w rule is implemented, user 605 only has write permissions.
Setting Default ACLs

Two types of ACLs can be used: access ACLs, and default ACLs. So far, this chapter has only discussed access ACLs. Access ACLs are set for individual files and directories. Directories, and directories only, can also have default ACLs, which are optional. If a directory has a default ACL set for it, any file or directory created in the directory with default ACLs will inherit the default ACLs. If a file is created, the access ACLs are set to what the default ACLs are for the parent directory. If a directory is created, the access ACLs are set to what the default ACLs are for the parent directory and the default ACLs for the new directory are set to the same default ACLs as the parent directory.

To set the ACL as a default ACL, prepend d: to the rule such as d:g:500:rwx to set a default ACL of read, write, and execute for user group 500. If any default ACL exists for the directory, the default ACLs must include a user, group, and other ACL at a minimum as shown in Listing 7.12.
Listing 7.12. Default ACLs

# file: testdir
# owner: tfox
# group: tfox
user::rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:other::r--

If a default ACL is set for an individual user other than the file owner or for a user group other than the group associated with the file, a default effective rights mask must also exist. If one is not implicitly set, it is automatically calculated as with access ACLs. The same rules apply for the default ACL effective rights mask: It is recalculated after an ACL for any user other than the owner is set or if an ACL for any group including the group associated with the file is set, meaning it should be set last to ensure it is not changed after being set.
Removing ACLs

The setfacl -x command can be used to remove ACL permissions by ACL rule type. The for this command use the same syntax as the setfacl -m command except that the field is omitted because all rules for the rule type are removed.

It is also possible to remove all ACLs for a file or directory with:

setfacl --remove-all

To remove all default ACLs for a directory:

setfacl --remove-default

Preserving ACLs

The NFS and Samba file sharing clients in Red Hat Enterprise Linux recognize and use any ACLs associated with the files shared on the server. If your NFS or Samba clients are not running Red Hat Enterprise Linux, be sure to ask the operating system vendor about ACL support or test your client configuration for support.

The mv command to move files preserves the ACLs associated with the file. If it can’t for some reason, a warning is displayed. However, the cp command to copy files does not preserve ACLs.

The tar and dump commands also do not preserve the ACLs associated with files or directories and should not be used to back up or archive files with ACLs. To back up or archive files while preserving ACLs use the star utility. For example, if you are moving a large number of files with ACLs, create an archive of all the files using star, copy the star archive file to the new system or directory, and unarchive the files. Be sure to use getfacl to verify that the ACLs are still associated with the files. The star RPM package must be installed to use the utility. Refer to Chapter 3 for details on package installation via Red Hat Network. The star command is similar to tar. Refer to its man page with the man star command for details.





Reference:http://www.informit.com/articles/article.aspx?p=725218&seqNum=5