A reminder: Unix file access rwx permissions are simple but tricky

As users of Unix-like systems, we are quite used to everyday rwx access bits of a file system. They are simple and intuitive. I guess, many of us read a manual or two about it once in life, but one tricky moment can still be unrevealed or forgotten due to its use case being relatively rare.

Let’s get a file:

So, the file owner is igoro uid with Read and Write permission bits set, and the file group is igoro gid with Read bit only. And "others" have Read access bit set. Okay, having a shell process with respective effective creds, we get read access to the file as expected:

Now let’s remove that Read bit from the file owner:

Hmm, but I’m part of igoro group which has Read access…​

Well, I have revised some related manual, for instance, man 9 vaccess and I’ve found out a funny thing about myself. It’s turned out that decades ago the manual, perhaps, did not make it clear in my head that the logic is NOT the same as "owner bits are checked first, then group ones, and others after". For some reason (cognitive stuff, huh?) my intuition and existing experience left me with a feeling that it works like this, even after reading the documentation. Or, probably, I had got the idea right but forgot it later, because I had no such use cases and my intuition was based on common sense which comes from the usual computer user experience.

And recently I’ve got acquainted with the source code behind and surprise surprise, the actual mechanism looks very clean and obvious when I note it from the code itself. It shows that first of all we pick which rwx set will be used (user, group, or others) by matching uid/gid. And only after that we match the bits within the chosen set. And if we fail on bits level then this is the end of the story — we do not consider any other rwx set. Yes, there are privileges, but it’s an additional mechanism that does not change the main logic.

The roots of this behavior could take us back in old good Unix times, and contemporary Unix-like operating systems still keep this logic:

Probably, there are adequate reasons why it’s done so and it needs more experienced Unix history scholar to explain. But from a usual user perspective a logical question may spin around why it’s not fixed yet. I think it’s the same answer as to all the similar questions about JavaScript as an example, where the common answer is "It would destroy the Internet!".

As a result, the amusing thing for me is that having long experience in programming I got the idea easier and quicker from the code than from its documentation — usually it’s the opposite.

Is it a documentation issue? I don’t think so, it’s respected and hard work to explain technical topics, especially in a concise form. The main reason is simple and usual — our main tool (brain, The) is not ideal. In my case, my human learning model was trained more around common use cases, and for many years it has been giving me the wrong answer regarding this specific situation. Fortunately, it is not a critical topic for me. So, it’s a reminder for me that source code is the source of truth and sometimes it explains quicker and unambiguous way.

I guess it’s a rare case to face this Unix access mode peculiarity in real life. And a common recommendation would be to avoid tricks usage if possible, this is about access control after all. But, IT happens.

Copyright © Igor Ostapenko
(handmade content)