0

It may be rare to do so, but if one created a file and revoke the permissions, the owner (as well as the group users) can no longer access the file.

midnite@gentoo_bazic /home/midnite % touch file
midnite@gentoo_bazic /home/midnite % chmod 007 file
midnite@gentoo_bazic /home/midnite % ls -l file
-------rwx 1 midnite midnite 0 Apr 13 02:22 file

Owner lost control of his own file.

midnite@gentoo_bazic /home/midnite % cat file
cat: file: Permission denied
midnite@gentoo_bazic /home/midnite % echo 'text' > file
zsh: permission denied: file

Even other users in the same group cannot alter the file neither.

midnite@gentoo_bazic /shared % touch file
midnite@gentoo_bazic /shared % chgrp m_group file
midnite@gentoo_bazic /shared % chmod 007 file
midnite@gentoo_bazic /shared % ls -l file
-------rwx 1 midnite m_group 0 Apr 13 02:41 file

midnite2@gentoo_bazic /shared $ cat file 
cat: file: Permission denied
midnite2@gentoo_bazic /shared $ echo 'else' > file 
bash: file: Permission denied

gentoo_bazic ~ # cat /etc/group | grep m_group
m_group:x:1002:midnite,midnite2

Of course if the user has write and execute permissions on the directory, he can remove the file (including delete, rename, or moving to another location). This has nothing to do with the file's permission.

However I feel this behaviour quite non-trivial. Many would think the [o]ther permission means every user in the system. It turns out it is everyone BUT the owner nor the group.

Any design rationales behind this property? Any meaningful scenarios where this setting is logical?

midnite
  • 325
  • 1
  • 3
  • 13
  • 5
    "Many would think the [o]ther permission means every user in the system" that's surprising to me. It's "other", not "all". Simply saying "a, b and others" implies "others" is people other than a and b. Besides, if user and group are covered elsewhere, why duplicate things for those and make things unnecessarily complicated? – muru Apr 12 '22 at 19:16
  • 1
    The file owner can change the permissions, so they can't get locked out. And isn't the possibility of excluding a particular group rationale enough? Also the way it is means the code only ever needs to check one permission bit, instead of chasing up to three, sounds simpler. – ilkkachu Apr 12 '22 at 19:16
  • It works the same way if you do `chmod 077 file`: now the owner can no longer access it, but other members of the group can. – Nick Matteo Apr 12 '22 at 19:17
  • 1
    I'm not sure which part it is you're mentioning is non-trivial, just the user-group-others behaviour, or the behaviour of the directory permissions too. (The latter ones have been dealt with in multiple answers on unix.SE too, and yes, like muru says, [citation needed] on your "many would think".) – ilkkachu Apr 12 '22 at 19:18
  • @NickMatteo, doing `chmod 0777 file` is a red herring, the file owner can just change the permissions bits back, so it doesn't mean anything. – ilkkachu Apr 12 '22 at 19:19
  • @ilkkachu: Yes, also if you do `chmod 007`. The point is that it only checks the most specific permission, so if you're the owner, it doesn't matter if you're also in the file's group or not. – Nick Matteo Apr 12 '22 at 19:22
  • @NickMatteo, yes. But so what? Why should that be a problem? Just don't run `chmod 0xx`. – ilkkachu Apr 12 '22 at 19:24
  • Thanks all. All comments together are great answers. Esp mentioning the owner can always change it back, group is excluding the owner too (consistent), and faster checking for only one bit. – midnite Apr 12 '22 at 19:40
  • 3
    Does this answer your question? [Restrictive "group" permissions but open "world" permissions?](https://unix.stackexchange.com/questions/276306/restrictive-group-permissions-but-open-world-permissions) – Stephen Kitt Apr 12 '22 at 20:57
  • @ilkkachu: no one says anything about it being a problem. And when you're trying to figure out what `0xx` permissions mean, like in this question, "don't run `chmod 0xx`" is the exact opposite of the advice I'd give! Definitely run it and see what happens. – Nick Matteo Apr 13 '22 at 01:37
  • @NickMatteo, the question read to me as if it was a problem for the poster, given the "Many would think the [o]ther permission means every user in the system" statement. The whole issue goes away if the "u" permissions are always equal to or greater than the "o" permissions. That's what everyone does anyway, and then no-one needs to think about which way it works. – ilkkachu Apr 13 '22 at 08:46

1 Answers1

3

The permissions work like this:

If the UID of the file matches the UID of the $USER, use the owner permissions (-rwx------).
Else if the GID of the file matches one of the groups $USER is a member of, use the group permissions (----rwx---).
Else use the world permissions (-------rwx`).

Once $USER is classified, there are no second chances.

waltinator
  • 4,439
  • 1
  • 16
  • 21