Basic AIX Permissions

Answer

Basic permissions in AIX are used to limit access to files/directories. There are 3 basic operations on files that are limited by permissions: read(r), write(w), and execute(x).

A sample "ls -l" output of a file called "libsearch" shows us the permissions at the beginning of the line:

-rwxr-xrw- 3 larry staff 102 Mar 3 2016 libsearch

Let us dissect this line.

The leading character in the first 10-character string tells us the file type; in this case, the character “-” tells us this is a regular file. Other possibilities would be “d“ for a directory, “s” for a socket, “b” for block special file, “c” for character special file, “l” for a link, and finally “p” for a FIFO special file.

The remaining 9 characters of this 10-character string are the permissions of the file. We break these up into 3 sections as follows:

The first 3 characters are called the “user” permissions. This is the “rwx” in the sample above. Later in the sample "ls -l" output, we see the name “larry”. This is the “user” owner of the file. According to the permissions set on this file, the user “larry” would be able to read the file, modify the file, or execute the file (if it were an executable or script).

The second set of 3 characters, “r-x”, are what is referred to as the “group” permissions. Following the name “larry" in the "ls -l" output above is “staff”. “staff” is a group that may consist of multiple users. These users would have read access and execute access to the file, as the “r” and “x” character are present in the 3-character set. The “-“ where the “w” was in the first example indicates that write permissions are explicitly not granted to the group "staff". The characters “r", “w”, and “x” will always appear in that specific order in a 3 character permissions set. If one character is missing, then that particular file operation is denied.

The third and final 3-character set of characters, “rw-“ in our "ls -l" example above, are the “world” or "other" permissions. These are the permissions for everyone else not covered by the first two 3-character sets. In our example everyone else would have read and write access, but not the ability to execute.

Basic permissions in AIX behave somewhat differently for directories than they do for files. Having a certain permission for the parent directory does not provide the same permissions to the contained files. I.e. having read access to the parent directory does not give you read access to all the contained files.

To clarify the behavior differences, let us take them one by one. For files, an “r” character means you can read the contents of the file. For a directory, “r” means you can list the contents of the directory. For files, a “w” means you can change the contents of the file or edit the file. For a directory, a “w” means you can change the contents of the directory, namely creating or deleting files. An “x” permission for a file allows you to execute or run the file. For a directory, the “x” allows you to enter the directory or traverse it with a cd command.

There are additional basic permission characters that may appear in the "ls -l" output. Let's look at the following "ls -l" output:

-r-sr-sr-x 3 root security 1077 Nov 17 11:17 /usr/bin/runme

Notice that there are "s" characters where the "x" characters normally appear. These are called the SETUID(or SUID) and SETGID(or SGID) bits. The SETUID "s" character that appears in the "user" section of the permissions means "when this file is executed, run it as if the user owner had run it". If our user "larry" had executed this /usr/bin/runme file, it would be run as if the owner of the file had executed it - in this case, it would be run as "root". This is normally referred to as running the file with root privileges or root authority. Caution should be taken when setting a script as SETUID root, as root authority can do pretty much anything on the system. A poorly written or malicious script can have detrimental effects on a system when run with root authority. SETUID set on a directory has no functionality in AIX.

The second "s" character in the group section, called the SETGID bit, is very similar to the SETUID bit. When the file in our example above is run, it is executed with the same authority as anyone in the "security" group, as the group owner of the sample file is "security". SETGID can also be set on a directory. When set on a directory, SETGID forces all files created in that directory to be created with the same group owner of that directory, regardless of the group or groups that the file creator is a member of. In this example:

dr-xr-sr-x 3 phil monitors 1077 Nov 17 11:17 /usr/local/monitoring

All files created in /usr/local/monitoring will have the group owner set to "monitors".

The final special character in AIX is the "t" bit, or "sticky" bit. The most common use of the sticky bit can be seen in /tmp as the default permissions contain the the "sticky" bit. When the sticky bit is set in a directory, all files created in the directory will only be able to be removed by their creator or by root. The sticky bit has no meaning for regular files.

One final note on the special characters "s" and "t". They share a position with the "x" character in the permission 3-character set. It is possible to have execute permissions on or off while using SETGID, SETUID, or the sticky bit. In order to be able to distinguish whether the execute(x) bit is set or not, we use case to differentiate. If the "x" bit is set, then we use a lower case "s" or "t". If the "x" is not set, we use the upper case "S" or "T".

Special notes on permissions:

The root user is not affected by file access permissions on local files, but may be affected by file access permissions on remote files accessed via NFS.


Like the example we used, permissions for a file can be seen with "ls -l". Changing permissions is done with the chmod command. For more details, see the manpage for chmod. If the permissions for a file are not behaving as described above, there may be ACLs (Access Control Lists) defined for the file; ACLs may also be referred to as extended permissions. See the manpage for acledit for more information about ACLs if you think there may be ACLs affecting your file and wish to change them.