Controlling UNIX file permission with umask Oracle Tips by Burleson Consulting

Controlling UNIX file permission with umask

UNIX has a default permission mask that is used by default by everyone who accesses the Oracle server. This permission mask is known as umask, and the value of umask controls the default file permissions whenever you create a new UNIX file.

Normally the umask is set system-wide in the /etc/profile file so it applies to all users on the system. However, often the Oracle DBA will override the default umask by re-setting it in their login file (.profile or .cshrc).

The values for umask are different depending upon whether the file is executable. The umask for the creation of new executable files is calculated base don the value of umask. In this case, we have set umask=022:

777 Default Permissions
-022 Subtract umask value, for example
-----
755 Permissions of new file

For executable files, the value of umask is computed by taking the difference between 777 (read-write-execute) and the actual value of umask. The following table illustrates:

Umask value
022
001
143
File permission
755
776
637
Total
777
777
777

Each user has a file creation mask, called an umask, which controls what permissions are given to a file when it is created. The umask setting can be examined using the umask command.

$ umask

0022

By default, the umask setting is displayed in a format that is subtracted from a system wide default permission, typically 666 for files and 777 for directories, but an easier way to view these permissions is to add the -S option. This shows how the permissions are applied to files using the symbols rather than numbers.

$ umask '€“S

u=rwx,g=rx,o=rx

The umask can be set using the umask command as well and the new file creation mask takes effect immediately.

$ umask -S u=rwx,g=rwx,o=rx

u=rwx,g=rwx,o=rx

$ umask '€“S

u=rwx,g=rwx,o=rx

The new umask setting remains in place for the remainder of the command line session. If the umask needs to be persistent between sessions, the umask command can be added to the user's .bash_profile or another appropriate login file.

How Permissions Affect Directories

Directory permissions are changed in the same method as file permissions, but the results can be rather surprising and sometimes confusing. To examine the permissions on a directory, use the -ld option for the ls command. This shows the properties of the directory rather than listing its contents. Here are the typical directory permissions:

$ ls -ld example/

drwxr-xr-x 2 oracle dba 4096 Oct 29 22:38 example/

On directories, the read permission controls the ability to list the contents of a directory. By removing the read permission from your example, you see that you no longer can list the contents of the directory:

$ chmod u-r example/
$ ls example/

ls: example/: Permission denied

$ cd example/
$ pwd

/home/oracle/example

$ ls

ls: .: Permission denied

Even after changing the directory into example, the contents cannot be listed; however, it is significant that cding into the directory can be done.

The write permission on a directory controls whether a user, group or other users can create or delete a file or subdirectory of a directory. However, the execute permission has the unexpected behavior of controlling if a user can cd into a directory. To demonstrate, replace the read permission and remove execute on the example directory.

$ cd ../
$ chmod u+r example
$ chmod u-x example
$ ls example/

anotherfile.txt log2.log myfile.txt sample.txt types_of_unix.txt
log1.log log3.log output.txt test_script.sh
$ cd example/
-bash: cd: example/: Permission denied

This shows that after removing the execute privilege, listing the contents of the directory can be done, but the DBA cannot cdinto it. If a directory needs to be made viewable to other users, it is best to share both the read and execute privileges so users can both list and cd into the directory.