How Permissions Work

About this document
    Related documentation
How do I see the permissions on a file?
Which set of permissions apply to me?
What do the permission letters mean?
    For a directory
    For a file
What determines the permissions on a file or directory when I create it?
How do I change the owner or group on a file or directory?
How do I change the permissions on a file or directory?
SETUID behavior in AIX
What are Access Control Lists (ACLs)?
File systems and the underlying mount point permissions
Permissions on Network File Systems (NFS) mounted file systems
ftp does not use the umask setting when creating a file

About this document

This document describes how all levels of AIX control access to files and directories. All files and directories have permissions for the following.

Owner (who usually created the file)

Group (anyone that has this group in their group set or as a primary group)

Other (any user that is not the owner or does not have this group)

How do I see the permissions on a file?

Executing ls -l file_name or ls -ld directory_name shows various data, including a string of 10 characters on the left:

       -rwxrwxrwx

This character string can be broken up into the three permission sets:

       -rwx rwx rwx
       ^   ^   ^
       |   |   | Permissions for others
       |   |
       |   | Permission for users that have this group as
       |     their primary group or as part of their group set.
       |
       | Permissions for the owner of the file or directory

These commands also show an owner and a group for the file or directory:

       -rwxrwxrwx [some number] joe joegroup
           ^                     ^     ^
           |                     |     |
           permissions           owner group

The displayed name for the owner is taken from /etc/passwd. The file's inode stores the user id (a number). If you see a number instead of a name, either the /etc/passwd file is not readable or that user id is missing from the file. The name of the group is taken from /etc/group. Again, only a number is stored in the file's inode.

Which set of permissions apply to me?

The system first checks to see if you are the owner; if so, you get the owner's permissions, even if these permissions are more restrictive than the "group" or "other" set.

The system also checks to see if you have the group listed as either your primary group or as part of your group set. If so, you get the group permissions, even if these permissions are more restrictive than the "other" set.

If you are not the owner or part of that group, you get the permissions for "other."

What do the permission letters mean?

The meaning of permissions differ for a file or a directory. Permissions to read and write in a directory (a directory is merely a file with a list of names and pointers) are independent of permissions to read and write the files pointed to by these entries.

The relationship of the directory to a file is detailed below.

directory: contains a list of the file names and the pointers to the inodes that contain the permissions for the file.
inode: contains the permissions for the file and a pointer to where data resides on the disk.
data: actual user data.

Directory permissions are required to find a file before opening it for use.

For a directory, permissions letters have the following meanings.

r: indicates the ability to read the list of files in a directory, such as with the ls command.

NOTE: You cannot execute a command inside the directory if the only permissions you have is to read the directory listing.

x: indicates the ability to pass through the directory (search). This allows you to operate on files in the directory if you already know the file names. Without read permission, you cannot read the entries but are allowed to access them. To use a file, the user must have search permission for all directories in the path. Users must also have the appropriate permission for the file itself.

In general, both read (r) and search (x) are required for most directory operations.

w: indicates the ability to create or delete files in the directory when coupled with the search (x) permission. If you have permissions to write at the directory level but no permissions on the file inside, you may still delete the file even though you may not modify the file. If you have only write permissions, you cannot change or modify the file.

NOTE: If you have write and search permissions at the directory level, you may delete the directory entry unless the link permissions bit (t) is set on the directory.

t: indicates link permission. When set, this bit prevents any user except the owner of a file, a root user, or the owner of the directory from deleting the file, even though the permissions on the directory would otherwise allow it. In such a case, the search (x) bit is set for "other."

T: is the same as lower case t but the search (x) bit is not set for "other."

s: is not used in the owner position. For the group position, this becomes the group inheritance bit (sgid, also known as set group id). Any files created in this directory have the same group as the directory entry. In AIX, when a new file system is created, this bit is set by default. This also means the search (x) bit is set for the group.

S: is the same as the lower case s but means the search (x) permission is not set for the group.

For a file, permissions letters have these meanings:

r: indicates the ability to read the file.

w: indicates the ability to change or modify a file. You cannot create or delete the file unless you have write permission for the directory.

x: indicates the ability to execute the file.

What determines the permissions on a file or directory when I create it?

Your user id (uid) is used to set the owner of the file. Your primary group is used to set the group (unless the directory in which the file is created has the sgid permission bit set; then the group is the same as the group on the directory entry). The id command can be used to see the uid and primary group for that user. Your umask setting is used to set the initial permissions. Type umask at the command line to see the current setting. To change the umask setting, type umask number, as in:

umask 022

NOTE: You do not use the equal sign (=) when setting umask.

umask does not set the execute bit on a text file or shell script but only on a directory. To determine what umask to use, take the umask setting and subtract it from 777 for a directory or from 666 for a text file or shell script. Then, if you create a directory or text file, you see permissions as follows:

Example with umask 022:

777 - 022 = 755
666 - 022 = 644

Executing ls -l shows the following permissions:

for a directory: rwxr-xr-x

for a text file: rw-r--r--

How do I change the owner or group on a file or directory?

The chown and chgrp commands are used to change owner and group. Only the root user can change the owner of a file. You can change the group of a file only if you are a root user or if you own the file. If you own the file but are not a root user, you can change the group only to a group of which you are a member. To change the owner and group at the same time, use the chown command.

To use the chgrp command:

       chgrp <new_group_name> <file_name>

To use the chown command:

       chown <new_owner> <file_name>

       chown <new_owner.new_group> <file_name>

How do I change the permissions on a file or directory?

Use the chmod command to change the permissions on a file or directory. Permissions can be expressed using either letters or numbers.

CAUTION: If you are using Access Control Lists, (ACL), on a file or directory, using the numeric mode of the chmod command will disable the ACL.

The following general syntax for numeric mode should be run on one line as:

       chmod <special bits> <owner> <group> <other>
<file_name or directory>

The numeric mode uses numbers for each position---owner, group and other. For each position:

read (r) = 4
write (w) = 2
execute [or search] (x) = 1

These numbers are added together to get the numbers to use for the chmod command. For example:

owner has read + write + execute = 4+2+1 = 7

group has read + write = 4+2 = 6

other has read = 4 = 4

The chmod command would be chmod 764 file_name

To set the special bits, suid (set user id), sgid and link bits requires a fourth number for the chmod command.

suid = 4
sgid = 2
link = 1

To add the suid permissions to the preceding example, the command is:

       chmod 4764 <file_name>

To use the symbolic mode, you specify which position owner (u), group (g), other (o) or all (a) to change and what symbol to add (+) or subtract (-). To add read + write to the owner use both:

       chmod u+r u+w <file_name>

       chmod u+rw <file_name>

If the sgid bit is set on a directory, the symbolic mode must be used to unset it:

 
       chmod g-s <file_name>

The numeric mode will not produce an error but the sgid bit will still be set.

************************************************************ 
                    SECURITY RISK 
WARNING:  Current UNIX(r) security manuals 
warn SUID/SGID shell scripts are a major security risk and 
are to be avoided.  This document reintroduces a POTENTIAL 
SECURITY RISK to your system! 
************************************************************

SETUID Behavior in AIX

A fix for a potential security risk dealing with the use of the SETUID and SETGID permission bits on shell scripts was included in AIX 3.1.7 (which corresponds to update level 2007). Prior to 3.1.7, when a shell script was executed whose permissions included the SETUID bit (set user-id), the shell script ran with the permissions of the shell script's owner. Similarly, if the SETGID bit (set group-id) was set, the shell script ran with the permissions of the shell script's group. Beginning with AIX 3.1.7, the SETUID and SETGID permission bits are no longer supported for shell scripts. This change does NOT affect compiled programs.

SETUID behavior in a shell script

Create a shell script named shell.sh that contains the following two lines. These lines should begin in the left most column.
```
    #!/bin/ksh 
    id 
```
Set the shell script's file owner to root, and the permissions to rwsr-xr-x (SETUID bit on). Execute the following commands:
```
    chown root shell.sh 
    chmod 4755 shell.sh 
```
Prior to AIX 3.1.7, if an ordinary user named "joeuser" ran shell.sh, the output would be:
```
    uid=200(joeuser) gid=200(staff) euid=0(root) 
```
The euid=0(root) indicates that the user was effectively root while the shell script executed.

For AIX 3.1.7 and later, the output is:
```
    uid=200(joeuser) gid=200(staff) 
```
The SETUID bit no longer has any meaning for shell scripts. The means that the SETUID does not function as it does on other UNIX systems. Other versions of UNIX do pass the euid 0 to other kornshell scripts and child processes; thus, creating a security vulnerability unacceptable to AIX.

SETUID behavior in compiled programs

If your application requires the previous SETUID behavior, you can call the shell script from a small compiled program that has the SETUID bit set in its permissions.

Create a C program similar to the following named execsh.c. Note the full path name in the execvp call. This is a good idea for security reasons.
```
    main(int argc, char *argv[]) 
    { 
    execvp("/path/shell.sh", argv);  /* execute the shell script */ 
    exit(1); 
    } 
```
Compile and link execsh.c using the following command:
```
    cc -o execsh execsh.c 
```
Set the owner of the execsh to root and the SETUID bit on. Execute the following commands:
```
    chown root execsh 
    chmod 4755 execsh 
```
The SETUID behavior has not changed for compiled programs, so execsh will effectively become root when it is executed, and will pass these credentials to shell.sh.

Examples of non-root user executing a program with root permissions

To have a non-root user execute a program with root permissions, use the following:

Using your favorite editor, create a file and name it umksysb.c.
Put the following text in the file you just created.
```
    main () 
   { 
      setuid(0); 
      setgid(0); 
      system("/bin/mksysb -i /dev/rmt0"); 
    } 
```
Compile this program by executing the following command:
```
    cc umksysb.c -o umksysb 
```
Change the permissions by executing the following command:
```
    chmod 4755 umksysb 
```

Access Control Lists (ACL) can be used to specify particular users that can access these files. This can be used with other commands as well.

Another example of a non-root user executing a program with root permissions is shown in the following steps.

Using your favorite editor, open the following file:

    myshutdown.c

Put the following text in the file myshutdown.c:

    main() 
   { 
      setuid(0); 
      setgid(0); 
      system("/usr/sbin/shutdown -Fr"); 
   }

Compile this program by executing the following command:
```
    cc myshutdown.c -o myshutdown 
```
Change the permissions by executing the following command:
```
    chmod 4755 myshutdown 
```

NOTE: Making a program suid root only assigns uid 0 to the program. Additional code may be required to acquire root's environment using the setpcred and setpenv subroutines.

For further information on the chmod command, at AIX Versions 4.2 and earlier, see InfoExplorer or the man page for chmod.

What are Access Control Lists (ACLs)?

ACLs are an extension to standard permission bits. They allow fine grain control for each file or directory by modifying the standard permissions that are assigned to individuals or groups. There are three assignments you can make for each group or user:

PERMIT	Grants the specified access to the file or directory.
DENY	Restricts the specified access to the file or directory.
SPECIFY	Precisely defines the file or directory access.

NOTE: If a user is denied a particular access by either a deny or a specify keyword, no other entry can override that access denial.

The acledit command is used to create an ACL. First you must set the EDITOR/ environment variable with the full path to your favorite text editor. For example:

       export EDITOR=/usr/bin/vi.

Then use:

acledit file_name

This will bring up a screen like:

       attributes:
       base permissions
       owner(rcunning):  rwx
       group(staff):  r--
       others:  ---
       extended permissions
       disabled

To set the extended permissions, change the disabled setting to enabled:

       extended permissions
       enabled

Use the permit, deny or specify keywords to define the extended permissions. The preceding example shows that only the owner can write to this file. The group staff can read the file and other has no permissions. To allow user joe to read and write the file, use:

       extended permissions
       enabled
       permit   rw-   u:joe

To allow group joegroup to read the file, use:

       permit   r--   g:joegroup

You can fine tune the permissions by combining the multiple entries on the same line. If you want to give pete read and write access ONLY, and if he is currently part of the system group, use:

       permit   rw-    u:pete, g:system

To add permissions for several users or groups, use separate lines:

       permit   rw-   u:joe
       permit   rw-   u:pete

Further information on the acledit command appears in InfoExplorer for AIX Version 4.2 and earlier or the man pages.

Two other ACL commands can be used, aclget and aclput:

aclget file_name outputs the permissions to standard out.
aclget file_name file_with_permissions sets ACLs on file file_name from file file_with_permissions.

To copy the ACLs from one file to another, use:

       aclget <file_name> | aclput <new_file_name>

Use the ls -el command to see if an ACL is set on a file. For example, the ls -el .profile command shows:

       -rwxr-----+

The + in the last position means the file has an ACL enabled.

CAUTION: Using the chmod command with numeric arguments will disable the ACL for a file or directory.

File systems and the underlying mount point permissions

File systems are mounted over a directory mount point. Both the mount point and the file system have permissions. The permissions on the mount point are determined by the current umask setting at the time the file system is created. Even though the permissions on the mounted file system take precedence over the permissions on the mount point, the mount point must have at least search permissions for everyone (that is, 111) to avoid unpredictable results. Remember, after the file system is mounted, you cannot see the permissions on the mount point. You must umount the file system before the mount point permissions can be examined and changed.

When a file system is created, the default permissions come from a proto file (see mkfs in InfoExplorer at AIX Versions 4.2 and earlier for more details) and the sgid (group inheritance) bit is set. The user's umask is not involved for file systems but just for the underlying mount point.

Permissions on Network File Systems (NFS) mounted file systems

Network File Systems (NFS) are mounted on a local directory. The directory mount point is normally created when you first create the network mounted file system in the System Management Interface Tool (SMIT). The mount point uses the current umask setting to determine the permissions when it is created.

NFS mounted file systems use a special user id called nobody. This uid is normally a very large number so as not to conflict with any real user id. Unless the NFS server has an entry in /etc/passwd for your user id (not text name), the permissions you have when you remote mount a file system is for the pseudo user id nobody. If your user id happens to match some valid id on the remote system, you are now the owner of any files created by that owner. This can lead to unpredictable results. If you need to be able to create and own files on the remote system, your local system and the server system must have matching user entries (both user name and the same id number) in the /etc/passwd files. The file system must also be exported as read and write.

The root user is a special case. Since root is user id 0 on all systems, without special protection, any system that mounts the file system would become root on the server system. Because of this, the NFS file system must be exported with root access for any host names from which you require special root access. If the file system is not exported in this manner root then becomes user nobody and has the permissions of the group other.

ftp does not use the umask setting when creating a file

The ftp command does not use the user's umask setting. Use the ftp site umask x subcommand to change the ftp umask.

[ Doc Ref: 90605219514824 Publish Date: Dec. 15, 2000 4FAX Ref: 5888 ]

owner has read + write + execute	=	4+2+1	=	7
group has read + write	=	4+2	=	6
other has read	=	4	=	4