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

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?

  • 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, 2022 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, 2022 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. Apr 12, 2022 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, 2022 at 19:18
  • 3
    Does this answer your question? Restrictive "group" permissions but open "world" permissions? Apr 12, 2022 at 20:57

1 Answer 1


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .