Intuitive expectation
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:
$ echo 'A regular file.' > regfile
$ ls -l regfile
-rw-r--r-- 1 igoro igoro 16 May 15 08:27 regfile
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:
$ id
uid=1001(igoro) gid=1001(igoro) groups=1001(igoro),0(wheel)
$ cat regfile
A regular file.
Now let’s remove that Read bit from the file owner:
$ chmod u-r regfile
$ ls -l regfile
--w-r--r-- 1 igoro igoro 16 May 15 08:27 regfile
$ cat regfile
cat: regfile: Permission denied
Hmm, but I’m part of igoro
group which has Read access…
Source code is the best story teller
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:
-
My main code reference is FreeBSD source code
-
And the similar can be checked for the ubiquitous Linux kernel inside its source code
-
As long as todays macOS has some roots around FreeBSD it provides the same logic as well
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.
Conclusion
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)
From: Big Mongo <b**3@**mail.com>
Date: Thu, 15 Aug 2024 23:05:31 -0400
What are sticky bits and how/why are they used?
From: Igor Ostapenko <[email protected]>
Date: Fri, 16 Aug 2024 12:59:49 +0000
There is an interesting historical fact that, back in the early days of Unix, the sticky bit was used to ask the system to keep the most frequently used programs in memory. This was before the Virtual Memory feature.
Later, its meaning was switched to the access control area, for security measures. For instance, the /tmp directory is usually meant to be writable by anyone, hence, the rwx bits are set for Others. We add a sticky bit to the directory so that users can delete or rename only the files they are the User Owner of.
It’s added or removed through the same chmod program, like "chmod +t mydir".
Post a comment