It's counterintuitive that the owner can have less rights than the others. Honestly, I've never seen it put in practice in any real-world file system.
Incidentally, this is also not very efficient: UNIX permissions as they are today require 9 bits, namely rwx for owner, rwx for group, and rwx for others. But in an alternative universe where owner's rights win over group's rights which win over others' rights, permissions could be coded in just 6 bits: 2 to express who can read, 2 for who can write, and 2 for who can execute. Each set of 2 bits would be interpreted this way: 00=nobody, 01=only owner, 10=group or owner, 11=everybody.
Alas, you're missing some bits. Sticky bit in particular can be associated to each of those too. There's probably others that I don't remember off the top of my head.
> It's counterintuitive that the owner can have less rights than the others
I completely concur. I've also never seen it used in the wild, but I know about it because I stumbled upon it more than once building scripts and not being careful about what flags are set.
Why "alas"? I'm comparing apples with apples: UNIX base permissions vs alternative-universe base permissions. If you want to add the 3 flags (sticky, setuid and setgid), you can add 3 bits to both sides of the comparison.
I have had some colleagues who did not get the semantics either, for many features of Unix permission bits, not just the two mentioned above.
For example, some did not know how to use the symbolic form of the chmod command's permission flags, e.g., like ug+rx, only the octal ones, like 660, and would typically indiscriminately use 777, not knowing about the security risks :)
...especially when they don't read documentation as often as they should ;)
ahem
Yes, I mean the setuid bit. The bit that makes the groups work for read/write to a directory. The same bit that's dangerous if it's set for a root user or group, and can be iffy if it's executable... yes that bit.
I'd argue you could drop x as well. It's really an attribute not a permission, since you can copy a file without x then chmod +x it.
That fails for setuid files but that's a setuid thing not an x thing. It also fails I guess for executables that check argv[0] but probably not important.
Incidentally, this is also not very efficient: UNIX permissions as they are today require 9 bits, namely rwx for owner, rwx for group, and rwx for others. But in an alternative universe where owner's rights win over group's rights which win over others' rights, permissions could be coded in just 6 bits: 2 to express who can read, 2 for who can write, and 2 for who can execute. Each set of 2 bits would be interpreted this way: 00=nobody, 01=only owner, 10=group or owner, 11=everybody.