I just ran into something unexpected (for me) regarding file permissions on Linux (Arch Linux). Basically I have:

  • userX in groupX
  • fileX userX:groupX ---rwx----

What puzzles me: I cannot perform any action (rwx) on fileX. Is this right? Can someone please confirm this is indeed the expected behaviour?

The only actions I can perform are mv and rm because I have write permissions on the parent directory.

The thing is, I always thought these permissions collapse on each other, starting with the most general one (other -> group -> user). In other words, if o=rwx who cares what the persmissions for group and user are? Apparently this is not the case but it doesn't make much sense to me; it seems counterintuitive. The only thing this approach seems to be useful at, is to easily exclude a very specific person / group, which doesn't seem like a smart way to go at it (imho). Besides, the owner (and group?) should be able to chmod anyway right? Any thoughts on this matter?

  • are you definitely in groupX ?
    – exussum
    Jun 3, 2014 at 21:46
  • yeap, definitely; checked effective gid with id
    – alex
    Jun 4, 2014 at 6:42

4 Answers 4


The thing is, I always thought these permissions collapse on each other, starting with the most general one (other -> group -> user).

If it was the case then “other” permissions would apply to everyone.

In other words, if o=rwx who cares what the persmissions for group and user are?

That's different from your previous sentence. Here you're implying that the permissions are or'ed together, e.g. that userX has the read permission if userX owns the file and the file is user-readable, or if a group that userX belongs to owns the file and the file is group-readable, or if the file is other-readable. But that's not how it works. In fact, o=rwx means that the rwx permissions apply to others, but it doesn't say anything about entities that are not others.

First, it doesn't directly matter which groups a user belongs to. The kernel doesn't have a notion of users belonging to groups. What the kernel maintains is, for every process, a user ID (the effective UID) and a list of group IDs (the effective GID and the supplementary GIDs). The groups are determined at login time, by the login process — it's the login process that reads the group database (e.g. /etc/group). User and group IDs are inherited by child processes¹.

When a process tries to open a file, with traditional Unix permissions:

  • If the file's owning user is the process's effective UID, then the user permission bits are used.
  • Otherwise, if the file's owning group is the process's effective GID or one of the process's supplementary group ID, then the group permission bits are used.
  • Otherwise, the other permission bits are used.

Only one set of rwx bits are ever used. User takes precedence over group which takes precedence over other. When there are access control lists, the algorithm described above is generalized:

  • If there is an ACL on the file for the process's effective UID, then it is used to determine whether access is granted.
  • Otherwise, if there is an ACL on the file for the process's effective GID or one of the process's supplementary group ID, then the group permission bits are used.
  • Otherwise, the other permission bits are used.

See also Precedence of ACLS when a user belongs to multiple groups for more details about how ACL entries are used, including the effect of the mask.

Thus -rw----r-- alice interns indicates a file which can be read and written by Alice, and which can be read by all other users except interns. A file with permissions and ownership ----rwx--- alice interns is accessible only to interns except Alice (whether she is an intern or not). Since Alice can call chmod to change the permissions, this does not provide any security; it's an edge case. On systems with ACLs, the generalized mechanism allows removing permissions from specific users or specific groups, which is sometimes useful.

Using a single set of bits, rather than or-ing all the bits for each action (read, write, execute), has several advantages:

  • It has the useful effect of allowing removing permissions from a set of users or groups, on systems with ACLs. On systems without ACLs, permissions can be removed from one group.
  • It is simpler to implement: check one set of bits, rather than combining several sets of bits together.
  • It is simpler to analyse a file's permissions, because fewer operations are involved.

¹ They can change when a setuid or setgid process is executed. This isn't related to the issue at hand.

  • 1
    well... by "collapsing" I kind of meant the same thing, an OR operation :)
    – alex
    Jun 4, 2014 at 6:48
  • thanks for your time; +1 for the very detailed and pretty technical answer
    – alex
    Jun 4, 2014 at 7:02
  • Great answer. But I have a question about your final bullet points: Is it really simpler to implement and analyze? Wouldn't checking permissions just come down to ORing the permissions together like OP thought was the case?
    – gardenhead
    Jan 4, 2016 at 21:57
  • This edge case seems silly to me still: (userX in groupX) + (userZ in groupX). You have a fileX userX:groupX ---rwx----. Now original folder creator userX cannot access fileX.. but userZ can. And they both part of the same group. Really unintuitive.
    – alexfvolk
    Mar 1, 2019 at 20:06

The more specific permissions take precedence over the less specific.

userX in groupX

fileX userX:groupX ---rwx----

Since you are the the owner of the file you will be granted only owner permissions. The owner has no permissions. Thus, you cannot do anything. Had you not been the owner of the file and a group member then group permissions would apply.

Please read this section of the wiki page



-rwxrw---- means the owner has read, write and execute permissions, the group has read and write, and others have no permissions.

The permissions you provided give the group 'groupX' permissions to read, write and execute the file. If you are a member of the group "groupX" but not the owner of the file these permissions will apply to you.

In this case I am assuming you are indeed the owner of the file. Only the permissions set for the owner will then apply to you. Of course the owner is able to override or change the permissions on the file. The group, however, can not do this. For example vim will prompt you to confirm if you are writing to a file that you don't have write permissions to but are the owner of.

I usually read permissions from left to right. Am I the owner? If yes, the owner permissions apply. If not; am I a member of the group? If yes, group permissions apply. If not, then the permissions for "Other" apply to me.

In some cases it is useful to be the owner of a file but not have write permissions. It protects you from accidentally deleting or modifying the file. Personally I have set the permission 400 on all my template files, just to make sure I don't modify them by accident. The same goes for execute permissions.

  • 1
    I believe you misunderstood the question. When the OP said the permissions "collapse" as Others->Group->User, I think they meant that when determining whether your action is permitted, first "Others" permissions are checked, then "Group" ones and finally (if all else fails) "User" ones.
    – Joseph R.
    Jun 3, 2014 at 21:17
  • @JosephR. yeap, that's what I meant :)
    – alex
    Jun 3, 2014 at 21:19
  • Oh, my apologies. I will remove that part. Is there anything useful in the answer?
    – arnefm
    Jun 3, 2014 at 21:21
  • Note: you should edit your answer a bit and remove (or rephrase) the second paragraph as it's kind of "obscure" (it's not clear enough, kind of contradicting the behavior I described)
    – alex
    Jun 4, 2014 at 6:56
  • On second thought, I might have been to quick to accept the answer. Sorry about that. So you are saying that sometimes it's useful to not have write permissions so you don't accidentally change some important files; but what good is it when others have full permissions? (so... you will be stopped from making mistakes but not others)
    – alex
    Jun 4, 2014 at 8:19

I was able to add a user to a group, give the group permissions to a directory (070), and then AFTER RESTARTING was able to access the folder.

Create group: sudo groupadd groupname

Add user to group: sudo gpasswd -a username groupname

Make sure entire directory is under correct group ownership (must be current member of groupname to perform): sudo chgrp -R groupname directory_path/

Give only the group rwx for the folder (could just be rw, adjust as needed): sudo chmod -R 070 directory_path

After doing the above, make sure to logout and back in. If that doesn't work, restart the machine. Doing this worked for me.

  • was username the owner of the directory? if not then you misunderstood the question
    – alex
    Dec 20, 2019 at 16:17

You must log in to answer this question.

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