Logic Behind User Masks(umask)??
Posted by Own_Wallaby_526@reddit | linuxadmin | View on Reddit | 22 comments
Hey, I am new to learning Linux system administration and I wanted to ask this:-
What is the point of umask(user masks)? I get the default permission part but I don't like the subtracting part of it. Why can't processes/programs who create files just have base permissions set for the type of the file(directory, regular files, sockets, symbolic links.....).
We already do have base permissions which are global and umask for different processes. Again, why couldn't we just have had base permissions changing depending on the process??
Why go the lengthy route of subtracting from the base permissions to get the actual permissions??
wise0wl@reddit
Don't think of it as a single number that's being subtracted. It is, but it doesn't work that way in practice. What you are doing with a umask is setting specific bits to zero. Those bits represent specific permissions. So if you set a specific umask it will always mask those bits and set those permissions off. So, if you don't want a process to have the "other" bits set (read, write, execute, directory execute) you can mask just those bits.
You don't have to know the existing permissions and then iterate through things to figure out the new permissions, just mask the bits you want to mask and let it go.
ironwaffle452@reddit
if you can set specific bits to zero they could invent set specific bit to 1 lol and call them "default permission" based on process/ user etc...
Own_Wallaby_526@reddit (OP)
What I learnt from your reply is that the umask, in practice, is just to set off certain bits. Like, let's consider that you don't want the 'write' bit to be set. The base permissions is 6(read + write), then it would just leave you with 4(read). This works perfectly.
But what if the base permissions were 5(read + execute). Now a umask with 2 set would delete 2 from 5 which will give you 3. And now you have (write+ execute).
wise0wl@reddit
OK, so bits. You are thinking in the numbers of the octal, which isn't it. It makes more sense if you look at the actual system call that's being called, in C.
https://man7.org/linux/man-pages/man2/umask.2.html
If you want to understand what's going on under the hood look up bit masking. https://stackoverflow.com/questions/10493411/what-is-bit-masking
If you want to ensure specific permissions for user, group, or other are removed you can use the aliased symols, like "g-wrx" etc.
Own_Wallaby_526@reddit (OP)
Thank you. I didn't know about bit masking.
zoredache@reddit
If you ever plan on doing anything with networking learning bitmasking is essential. The subnet mask, is just a bitmask with the restriction that the 1's are contiguous.
Own_Wallaby_526@reddit (OP)
I am thinking of learning CCNA with the RHCSA networking part for a deep dive.
I tried getting my CCNA a couple of years ago but I didn't cause even though I liked the networking part, I had no intention of getting into Cisco IOS CLI and getting a network admin/technician position.
Now, with RHCSA, it all seems very exciting to me once again.
So thanks, I will keep the bit mask part in mind for my networking journey.
tenuki_@reddit
Pro tip. Learning C to even a beginner lvl will pay rich dividends to your understanding of Linux.
HeyMerlin@reddit
I’m quoting an answer from askunbuntu as it does a good job in explaining: —- First of all, “mask” does not mean “subtract”, in the arithmetic sense – there is no borrow or carry involved.
Secondly, a “mask” should be understood bitwise instead: applying logical operations on each bit column independently. That is, the 4th bit of the permission bit-sequence interacts with only the 4th bit of the mask.
Third, the mask turns off permission bits. If they are already off, the umask makes no change to the permission,
For example, assume that you have to unmask 077 from the system defaults for files which is 666 and directories which is 777.
The command you will use is
umask 077 (unmask value in binary, 000 111 111)
What this unmask will do is it will turn off any of the first six LSBs (least significant bits) if they are 1 and will make no change if any of them are already off.
Here is how the final permission is calculated:
file permission 666 = 110 110 110 unmask value 077 = 000 111 111 will result in 600 = 110 000 000 Observe how both 110 values have changed to 000.
Similarly,
directory permission 777 = 111 111 111 unmask value 077 = 000 111 111 will result in 700 = 111 000 000 —-
So in you example of 5 and 3 you would get: Base permission 5 = 101 Umask value 3 = 011 Result is 4 = 100
So not arithmetic subtraction, bitwise subtraction in the sense of turning off set bits.
(Quote credit: https://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work)
Own_Wallaby_526@reddit (OP)
Thank you. I didn't have the bit level intuition on this. This all is making so much sense now.
icepic3616@reddit
Wait until you start learning about subnet masks :)
HeyMerlin@reddit
I’m quoting an answer from askunbuntu as it does a good job in explaining:
—-
First of all, “mask” does not mean “subtract”, in the arithmetic sense – there is no borrow or carry involved.
Secondly, a “mask” should be understood bitwise instead: applying logical operations on each bit column independently. That is, the 4th bit of the permission bit-sequence interacts with only the 4th bit of the mask.
Third, the mask turns off permission bits. If they are already off, the umask makes no change to the permission,
For example, assume that you have to unmask 077 from the system defaults for files which is 666 and directories which is 777.
The command you will use is
umask 077 (unmask value in binary, 000 111 111)
What this unmask will do is it will turn off any of the first six LSBs (least significant bits) if they are 1 and will make no change if any of them are already off.
Here is how the final permission is calculated:
Similarly,
—-
So in you example of 5 and 3 you would get:
So not arithmetic subtraction, bitwise subtraction in the sense of turning off set bits.
(Quote credit: https://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work)
maxlan@reddit
Yes. It isn't mathematical its binary masking..
5 is 4 and 1.
Take all the 2s out of 4 and 1 and you still have 4 and 1.
Entaris@reddit
Depending on context there are different permissions that might be set by default. umask isn't telling the system what permissions you want, its telling the system what permissions you dont want, which allows the system to do logic to derive sane permissions based on whatever context is there.
Remember that directories need execute permissions in addition to read permissions to be accessible. So to set defaults you have to account for the difference between 644 and 755.
By making it a simple bit mask it allows a user to set expectations easily, without creating weird logic around whether or not setting a default permission is going to accidentally end up with random files having execute permissions on them.
Remember that these were designed at a point where system resources were at a premium. every tiny bit of logic you put into any sort of process was costly. masking creates a simple global logic chain that lets a user set sane default permissions without having extra logic checks elsewhere
Own_Wallaby_526@reddit (OP)
It wasn't possible for Linux Developers to change it in modern times?? I get the functioning of all this from the replies in this section, but is it just legacy and efficiency that has led us to learn about bit masking in 2025? Today, outside embedded systems, don't we have enough system resources to actually set per process default permissions for numerous types of files? Or will changing it disrupt a huge chunk of Linux interface??
Entaris@reddit
linux is a slow beast to change, for many reasons. it was only a few years ago that we replaced init with systemd, which is arguably a big improvement to the original init.d system...and there are still forks that use init because people like the way it works (not to say it doesn't have its advantages over systemd, it does. but thats a different discussion). Hell we're not even at 100% wayland adoption as far as i know, and EVERYBODY hates X11.
Beyond that, we do have the file acl system. If you are unfamiliar you can use setfacl/getfacl for a more advanced "modern" way of managing file permissions.
Ultimately though, i think the main thing is that we have the resources to handle what might be a better system, but do we have a need? for 99% of the time umask works as needed, "fixing" it would be a change just to make a change.
Plus, remember that linux is not a monolith. there are a variety of different commands, even at the basic level that are maintained by a lot of different developers from a lot of different places
. To implement a fundamental change in file permission logic you'd need to either make a change complex enough to work flawlessly with any possible use case any random command may have found using the old system, or simultaneously get a bunch of different developers to all release an update to base commands all at once.
There is a guy, i can't remember his name, but at a linux convention (but its on youtube) that does two separate presentations: "Why Linux Sucks" and "Why Linux is Awesome" and they are basically the exact same presentation. One of the things he talks about that is both good and bad is the simple fact that linux isn't a project with one united mind guiding it. This means that every random person that has an idea can make a fork and try their idea out, which is awesome! There is probably a distribution out there that has totally revamped file permissions. It also means that every random person that has an idea can make a fork and try their idea out, and guess what that random distribution probably sucks. Its hard to get anywhere sometimes.
At the end of the day with linux it is: Be the change you want to see. If you think it can be better you can make that change happen. But if youdon't feel like its worth your time to make that change happen, odds are that is why that change hasn't already happened.
Own_Wallaby_526@reddit (OP)
Thank you for giving me a peek into how things move in reality. I am preparing for RHCSA and am mostly in my own bubble. This perspective of yours is refreshing and very much needed. I do plan to go into Linux development later. Hope to become competent enough to do that. But again, thanks for your perspective.
Entaris@reddit
Glad to offer some insight. Best of luck on the RHCSA test! It’s a fun one haha.
kai_ekael@reddit
umask is system-level, not application level. It is also situational.
Example I may need a specfic system where all files must have group write permissions where a number of accounts may create and modify files that all may later update.
michaelpaoli@reddit
Selectively deny (or possibly allow) permissions from what would otherwise typically be the default(s). Sorry if you don't like it, but that's how it is.
They do ... in part. E.g. typically text editors will create files with rw but no x permissions, they typically presume it's desired to be able to read and write it (hey, just created it, perhaps with nothing there ... probably want to edit it since you did that in a text editor, eh?), but probably don't want to execute it - at least unintentionally, so, x off, and can set that on when one is ready or before intending to actually execute it (at least for the first time). Likewise some other programs that operating in security sensitive contexts may further adjust permissions appropriately (or more specifically, will typically set umask appropriate in their context before creating files/directories. E.g. one might observe the behavior of visudo and ssh-keygen, and how they may behave even if umask is/were set to 0. And, yeah, generally shouldn't be using a umask of 0.
Other examples that jump to mind, mkdir generally defaults to including x permissions on directory - can't cd into the directory or generally stat contents of directory without that (with some exceptions or partial exceptions regarding stat, for some filesystem types). And compilers for binary executables, will generally set the x permission on the output binary file - at least if the compilation was considered successful.
But for various reasons (mostly historical and backwards compatibility), *nix often starts with a umask of 0, and then things further restrict from there, by tightening up umask, e.g. typically 022 or 027 or 077 for login sessions. Many OS flavors will also, early, and by default, at least reasonably tighten up umask, e.g. kernel or init system may tighten it up to at least 022 highly early on.
But the programs aren't mind readers. They have no idea if you want to share that text file you're editing that you just created with the entire world, or if it's some super-secret content you want to share with exactly nobody else. Likewise regarding who you may or may not want to allow to write(/edit) it, e.g. just yourself, or also those having same group membership, or do you want/trust all on the host to write/edit such? So, ... umask (and chmod, etc.) - but umask is often quite preferable, as that effects the initial permissions at creation. Note that *nix checks permissions at the open (or attempt thereof), once the file is open (for reading or writing or whatever), permissions mostly no longer matter for the process that has the file open - so generally best to start with proper permissions - so again, umask, rather than, e.g. create file rwxrwxrwx, and then change permissions after - as that generally won't protect it from other processes that have already opened the file and still have it open.
What are these "base" ... "global" permissions you speak of? Processes have a umask value, starting at least with init, if not kernel itself before that. So, what "global" permissions?
Anyway, *nix, and again, backwards compatibility, history, etc. - generally starts with a relatively permissive model, and one can then generally further tighten that up with umask or relevant configurations thereof.
So, anyway, very much a mask, and think of it that way. Permission bits to be turned off with the file creation, that would or might otherwise have been on/enabled, were the umask not there (or set to 0, as "not there" really isn't an option - all processes have a umask value).
gordonmessmer@reddit
Because there's no guarantee that every program you use will allow you to specify the "base permissions" that you want.
knobbysideup@reddit
Important if you are on a team that works on the same files, is a good example.
You'd want a default mask that sets group permissions to rw, and likely chmod g+s those directories as well.