Posted on 02/27/2019 3:25:59 AM PST by ShadowAce
Return, or set, the value of the system's file mode creation mask.
On Linux and other Unix-like operating systems, new files are created with a default set of permissions. Specifically, a new file's permissions may be restricted in a specific way by applying a permissions "mask" called the umask. The umask command is used to set this mask, or to show you its current value.
umask [-S] [mask]
-S | Accept a symbolic representation of a mask, or return one. |
mask | If a valid mask is specified, the umask is set to this value. If no mask is specified, the current umask value is returned. |
As you may know, each file on your system has associated with it a set of permissions that are used to protect files: a file's permissions determine which users may access that file, and what type of access they have to it.
There are three general classes of users:
In turn, for each of these classes of user, there are three types of file access:
So, for each of the three classes of user, there are three types of access. Taken together, this information makes up the file's permissions.
There are two ways to represent a file's permissions: symbolically (using symbols like "r" for read, "w" for write, and "x" for execute) or with an octal numeric value.
For example, when you list the contents of a directory at the command line using the ls command as follows:
ls -l
you will see (among other information) the file permission information for each file. Here, it is represented symbolically, which will look like the following example:
-rwxr-xr--
There are ten symbols here. The first dash ("-") means that this is a "regular" file, in other words, not a directory (or a device, or any other special kind of file). The remaining nine symbols represent the permissions: rwxr-xr--. These nine symbols are actually three sets of three symbols each, and represent the respective specific permissions, from left to right:
symbols | meaning |
---|---|
rwx | the file's owner may read, write, or execute this file as a process on the system. |
r-x | anyone in the file's group may read or execute this file, but not write to it. |
r-- | anyone at all may read this file, but not write to it or execute its contents as a process. |
The general symbolic form of a mask is as follows:
[user class symbol(s)][permissions operator][permission symbol(s)][,]...
permission symbol is any combination of r (read), w (write), or x (execute), as described above.
user class symbol may be one or more of the following:
u | User (the owner of the file) |
g | Group (any member of the file's defined group) |
o | Other (anyone else) |
a | All (equivalent to ugo) |
permissions operator may be one of the following:
+ | allow the specified file permissions to be enabled for the specified user classes (permissions that are not specified are unchanged in the mask) |
- | prohibit the specified file permissions from being enabled for the specified user classes (permissions that are not specified are unchanged in the mask) |
= | allow the specified file permissions to be enabled for the specified user classes (permissions not specified will be prohibited by the mask during file creation) |
So, for example, the following umask command:
umask u+w
sets the mask so that when files are created, they will have permissions which allow write permission for the user (file owner). The rest of the file's permissions would be unchanged from the operating system default.
Multiple changes can be specified by separating multiple sets of symbolic notation with commas (but not spaces!). For example:
umask u-x,g=r,o+w
This command will set the mask so that when subsequent files are created, they will have permissions that:
Note that if you use the equals operator ("="), any permissions not specified will be specifically prohibited. For example, the command
umask a=
Will set the file creation mask so that new files are inaccessible to everyone.
The file creation mask can also be represented numerically, using octal values (the digits from 0 to 7). When using octal numeric representation, certain numbers represent certain permissions, and these numbers are added or subtracted from each other to represent the final, combined permissions value. Specifically, the numbers 1, 2, and 4 represent the following permissions:
number | permission |
---|---|
4 | read |
2 | write |
1 | execute |
These numbers are used because any combination of these three numbers will be unique. The following table illustrates their unique combinations:
read value + | write value + | execute value = | combined value: | symbolic equivalent: |
---|---|---|---|---|
0 | 0 | 0 | 0 | |
0 | 0 | 1 | 1 | x |
0 | 2 | 0 | 2 | w |
0 | 2 | 1 | 3 | wx |
4 | 0 | 0 | 4 | r |
4 | 0 | 1 | 5 | rx |
4 | 2 | 0 | 6 | rw |
4 | 2 | 1 | 7 | rwx |
For each class of user, one digit can be used to represent their permissions; using the example above, we could represent the symbolic permission of rwxr-xr-- using the three-digit octal number 754. The order of the digits is always the same: User, Group, Other.
In octal representations of file permissions, there are actually four digits. The three important digits we've discussed are the last three digits. The first digit is a special file permission indicator, and for the purposes of this discussion can be considered always to be zero. So from here on out, when we discuss file permission 777, it may also be referred to as 0777.
The umask masks permissions by restricting them by a certain value.
Essentially, each digit of the umask is "subtracted" from the OS's default value to arrive at the default value that you define. It's not really subtraction; technically, the mask is negated (its bitwise compliment is taken) and this value is then applied to the default permissions using a logical AND operation. The result is that the umask tells the operating system which permission bits to "turn off" when it creates a file. So it's not really subtraction, but it's a similar concept, and thinking of it as subtraction can help to understand it.
In Linux, the default permissions value is 666 for a regular file, and 777 for a directory. When creating a new file or directory, the kernel takes this default value, "subtracts" the umask value, and gives the new files the resulting permissions.
This table shows how each digit of the umask value affects new file and directory permissions:
umask digit | default file permissions | default directory permissions |
---|---|---|
0 | rw | rwx |
1 | rw | rw |
2 | r | rx |
3 | r | r |
4 | w | wx |
5 | w | w |
6 | x | x |
7 | (no permission allowed) | (no permission allowed) |
So if our umask value is 022, then any new files will, by default, have the permissions 644 (666 - 022). Likewise, any new directories will, by default, be created with the permissions 755 (777 - 022).
To view your system's current umask value, enter the command:
umask
which will return your system's umask as a four-digit octal number, for example:
0002
Again, the first zero is a special permission digit and can be ignored; for our purposes, 0002 is the same as 002.
To view this as a symbolic representation, use the -S flag:
umask -S
Which will return the same value symbolically, for example:
u=rwx,g=rwx,o=rx
where u stands for user, g stands for group, and o stands for other. This is telling us the So if we create a new file, it will have the default permissions 664, which is 666 (the default permissions for files) masked by 002 (our umask value).
Let's test this by creating a new file with the touch command:
touch testfile
And now let's get a directory listing for that file:
ls -l testfile
-rw-rw-r-- 1 myusername myusername 0 Jan 7 14:29 testfile
As expected, the new file has permissions -rw-rw-r--, or 0664: The owner and group may read or write the file, and others may only read it.
Now let's change the umask. To set a umask of 022, use the command:
umask 022
This is the same as running umask 0022; if you specify only three digits, the first digit will be assumed to be zero. Let's verify that the change took place:
umask
0022
And now let's create a new file:
touch testfile2
And now let's view its directory listing, along with the first file we created, using the asterisk wildcard ("*") to view all files whose name start with "testfile":
ls -l testfile*
-rw-rw-r-- 1 myusername myusername 0 Jan 7 14:29 testfile -rw-r--r-- 1 myusername myusername 0 Jan 7 14:39 testfile2
As you can see, testfile2 has the permissions 644.
Here are some other example umask commands:
umask a+r
Sets the mask so that new files will allow all users to read them; other permissions will be unchanged from the default.
umask a-x
Sets the mask so that new files will not initially be executable by any user; other default permissions unchanged from defaults.
umask u=rw,go=
Sets the mask so that new files will be readable and writable by the user who owns the file, but may not be executed; group members and others will have no permissions to access the file.
umask 777
Make new files inaccessible to everyone - no one can read, write, or execute them.
umask 000
Make new files completely accessible (read, write, and execute) to absolutely everyone. However, this is a bad idea. Don't do this.
I remember the early days of the internet before WWW. Most of the time you were accessing UNIX systems. All text based using command lines. I remember logging into a server in Sarajevo during their civil war and thinking “well the country may be blown to hell but there is at least server running”.
"if our umask value is 022, then any new files will, by default, have the permissions 644 (666 - 022). Likewise, any new directories will, by default, be created with the permissions 755 (777 - 022)."
It is that third position that is important in this. The first octet refers to the Owner of the file, the second to the Group Owner, and the third to all Other users on the system. So, if you have a file with these permissions:
-rw-rw-r--
This means that the Owner can read and write to the file, any Group member can read and write to it, and all Other users on the system can read it.
Sometimes that's not really a problem from a security perspective, but I'd say that it is a bad habit to allow Other users to have access to any of your files by default. A better umask for this purpose would be 027, so by default if you create a file it will have permissions of 640 (-rw-r-----), and directories will have 750 (drwxr-x---).
Let's see what that looks like....
$ umask 0022 $ touch aaa $ mkdir aaaa $ ls -l -rw-r--r-- 1 amp amp 0 Feb 27 09:05 aaa drwxr-xr-x 2 amp amp 4096 Feb 27 09:06 aaaa $ umask 0026 $ touch bbb $ mkdir bbbb $ ls -l -rw-r--r-- 1 amp amp 0 Feb 27 09:05 aaa drwxr-xr-x 2 amp amp 4096 Feb 27 09:06 aaaa -rw-r----- 1 amp amp 0 Feb 27 09:22 bbb drwxr-x--x 2 amp amp 4096 Feb 27 09:22 bbbb $ umask 0027 $ touch ccc $ mkdir cccc $ ls -l -rw-r--r-- 1 amp amp 0 Feb 27 09:05 aaa drwxr-xr-x 2 amp amp 4096 Feb 27 09:06 aaaa -rw-r----- 1 amp amp 0 Feb 27 09:22 bbb drwxr-x--x 2 amp amp 4096 Feb 27 09:22 bbbb -rw-r----- 1 amp amp 0 Feb 27 09:22 ccc drwxr-x--- 2 amp amp 4096 Feb 27 09:22 cccc
Most would agree that it's better to have Other users have no access to their files by default. The downside is that if you're on a multiuser system and you do want to share files, you have to sometimes jump through extra hoops to do so. If you want others to have access to a specific file, you can always use chmod to change the file to less restricted settings....
$ chmod 644 ccc $ ls -l ccc -rw-r--r-- 1 amp amp 0 Feb 27 09:22 ccc $
Some programs check the permissions of it's files/directories. For instance the 'ssh' command will fail if your ~/.ssh directory is NOT set to 700 permissions. This makes sense as your encryption keys most emphatically should NOT be available to other users.
You can actually set even finer permissions if you want to on most modern Linux distros. For the advanced, and stout of heart look at the 'lsattr' command. It will allow you to lock a file down so much that not even the root user can delete/modify it.
For instance, for my own reasons, I really do not any program on my computer to mess with my DNS resolvers. If you look at my /etc/resolv.conf file, you'll see this...
$ ls -l /etc/resolv.conf -rw-r--r-- 1 root root 118 Jun 6 2018 /etc/resolv.conf $ lsattr /etc/resolv.conf ----i--------e-- /etc/resolv.conf $ sudo rm /etc/resolv.conf [sudo] password for zeugma: rm: cannot remove ‘/etc/resolv.conf’: Operation not permitted
Don't forget orphans and disowned processes!
Yup—I love ACLs. Although if you aren’t paying attention, they can cause some interesting times in your life, since they are not typically displayed in normal directory listings.
You and I appear to be rowing the same boat.
A common refrain among techie-types. Imagine being that sort of personality and getting a vindictive boss who punishes you by sending you to the call center to answer phones.
It sucks!
Huh?
This thread is about Linux specifically and Unix generally. Apple has nothing to do with it outside of the fact that MacOS is Unix and apple is a Unix contributor.
And I like my Mac, BTW.
More recently, there is an interesting extra code, which I occasionally know how to set and unset. When used, you end up with an extra “+” on the permissions, like:
-rw-r—r—+
I college, we used a version called “Multix”, which had some rudimentary machine-sharing properties; one particularly bad design had priorities that started “high”, and then would slowly lower until you had almost no priority, and then jump back to high.
People would get on the system, work 5 minutes, and then log off and back on, to get bumped back to the top of the queue.
I also remember using multix as my first word processor, using the “troff command.
The + sign means that ACLs have been set.
One of the reasons I like learning about Linux, is to hold on to my waning mental acuity. It's also the reason I've taken up music. YMMV. Thanks, S/A, for posting informative websites!
Next came Windows; I played around with Visual Basic, and did pretty good.
We had a visit from company headquarters in Japan, this was Fuji, who seemed excited about what I had created. He tooka CD of it back to Japan. Not long after, I got a nice gift from them. Banzai!
Next came Windows; I played around with Visual Basic, and did pretty good.
We had a visit from company headquarters in Japan, this was Fuji, who seemed excited about what I had created. He tooka CD of it back to Japan. Not long after, I got a nice gift from them. Banzai!
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.