Print-friendly Version

All About the umask and Permissions

By Carl Grammer

Why Can't I Create a File That Is Executable by Default?

Within UNIX, system calls have base permissions (sometimes referred to as "default permissions") with which to create new files and directories. For directories the base permissions are (octal) 777 (rwxrwxrwx), and for files they are 666 (rw-rw-rw). Before creating the file or directory, the base permissions are compared to a mask (the umask set by the umask command) that will "mask out" permission bits to determine the final permissions for the object being created. The calculation to determine the final permissions is to take the binary of the base permissions and perform a logical AND operation on the ones complement representation of the binary umask.

Just for fun, here is an example for creating a file with a umask of 022: The binary representation for octal 022 is 000010010. The ones complement simply inverts the numbers to make zeros equal ones and ones equal zeros, resulting in 111101101. Now if you perform a logical AND with the base permissions of 666 (binary 110110110) you end up with 644 (binary 110100100), as in the following example:

110110110    base permissions of 666
111101101    ones complement of a umask of 022
---------    perform logical AND, two 1s equal 1, 
             everything else equals 0
110100100    This converts to octal 644 which is rw-r--r--

The Bottom Line: Why Files Cannot Be Created With the Execute Bit Turned On

With the logical AND operation, both bits must be 1 (on) for the result to be 1. Since the base permissions for files has the execute bit set to 0 (off), it is impossible to create files with the execute bit turned on. You may notice some programs seem to create files with execute permissions turned on, but they are actually changing the permissions after the file is created.

An Easy Way to Determine File Permissions

Instead of performing the binary operation above, you can simply subtract the umask from the base permissions to determine the result. For the previous example, you would do the following:

666  Base permissions
022  umask value
---  subtract
644  permissions of new file (rw-r--r--)

Effect of Common Commands on File Permissions

By default the use of the commands cp and ftp will create target files using the rules previously described. However, if a target file of the same name already exists, the permissions of the existing file will be preserved (because no new file was created). This behavior can be modified with the -p parameter for cp, which will preserve the permissions of the source file. As far as I know, no such parameter exists for ftp.

The tar command, however, is a bit different. When extracting files, tar uses the permissions of each file (as the file was stored) as the base permission upon which to apply the umask. Depending on the umask, you may end up with some very interesting results. For example, files stored in a tar archive with permissions of 755 (rwxr-xr-x) and extracted with a umask of 333 will end up with permissions of 444; however, if the umask was 022 the permissions would remain 755. Files stored with permissions of 755 extracted with a umask of 027 end up with permissions of 750. (As you may have noticed, the easy method to determine the resulting file permissions doesn't work in this case; you must use the binary ones complement method to get accurate results.) To override this behavior on the tar command, use the p parameter. When extracting the archive, the p parameter will preserve the permissions as the file was stored.

About the Author

Carl Grammer is a Sun Certified System Administrator with over 15 years of IT industry experience. He is currently employed by an international IT consulting firm supporting the telecommunications sector.

The information and links on this page have been provided by a BigAdmin user. The submitter is solely responsible for such information and links. Sun is not responsible for the availability of external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. Sun will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss caused by or in connection with use of or reliance on the information posted here, or goods or services available on or through any external site or resource.