3

As I understand it, a file has 3 sets of permissions: owner permissions, group permissions, and everybody else permissions. Moreover, the file has is assigned to a owner, and a group.

How linux combines all this information, to actually determine the permissions a given user has over the file?

For example, say a file is:

--- rw- --x

That is, the owner has no permissions, the group can read/write, and everybody else can only execute.

Now user "Joe" comes to this file. Depending on which groups Joe belongs to, and whether Joe is or not the owner of this file, what can he do with it? He could execute the file, because x is set for everybody. But if "Joe" is the owner, x is forbidden for the owner. What takes precedence?

a06e
  • 1,727

3 Answers3

4

Linux permissions are exclusive of each other. So, owner permissions apply only to owner, group permissions apply to everyone in group except owner, and others permissions apply to others i.e. not group and owner. Only one of these permissions will be used depending on the UID and GID of the process that tries to access the file.

In your case, if Joe is the owner of the file, he can't do anything regardless of which group he is in.
If Joe is not the owner, but belongs to the group, he can read and write, but not execute.
If Joe is neither owner nor part of group, he can only execute.

Munir
  • 3,332
  • 1
    ... unless Joe has UID 0 in which case root fiat unless there's also some fancy ACL system or NFS involved ... – thrig Mar 15 '16 at 17:22
  • Given that the owner of a 061 file is also the owner of the directory the file lies in, he could still remove or move the file. Even if the file had a different owner or group as the directory, it could still be removed by the parent dirs owner. just learned this while playing around. Thx :) – pidi Mar 15 '16 at 21:22
  • 3
    @pidi I think that by moving the file between directories, you are not writing/reading/executing the file, you are only modifying the directories themselves. So the permissions on the file are not relevant. – a06e Mar 15 '16 at 21:46
  • @becko, unless there are extended attributes involved (e.g. immutability) and unless there is a sticky bit in play. – Wildcard Mar 15 '16 at 21:47
  • 1
    Also, in the example above, since Joe is the owner he can just chmod u+rwx the file and do anything he wants with it. But it's true he can't read/write/execute the file until and unless he chmods it. – Wildcard Mar 15 '16 at 21:48
  • @Wildcard So the owner can always change the permissions of a file? – a06e Mar 16 '16 at 06:57
  • 1
    @becko correct. The owner (or root) are the only ones who can change the permissions of a file, regardless of the current permissions that "group" or "others" may have. – Wildcard Mar 16 '16 at 08:34
1

Dmitry Grigoryev's answer above is correct. As a mnemonic, that's why we normally see permissions that are "wider on the left": u ≥ g ≥ o. Common modes are 755, 644, and 600. It's unusual, say, to deny the owner but allow the group. I'm sure I've never seen your 061 in actual use.

James K. Lowden
  • 2,080
0

The algorithm goes like this:

  • if you're the owner of the file, the owner permissions apply
  • else, if you're part of a group the file belongs to, group permissions apply
  • else, if the filesystem has ACL enabled and there are ACL entries mentioning you, those are applied
  • else, "other" permissions apply

In your example, if Joe is the owner of the file, he won't be able to do anything. If the file belongs to a group Joe is part of, he will be able to read or write, but not execute. If neither is true, Joe will be able to execute, but not read or write.

Dmitry Grigoryev
  • 7,313
  • I thought ACL doesn't kick in unless you have POSIX permissions as well. That is, ACL is ignored if user cannot perform the requested operation from standard permissions, – Otheus Mar 15 '16 at 17:35
  • So if Joe is the owner, and the file belongs to a group Joe is a part of, Joe won't be able to do anything. Correct? – a06e Mar 15 '16 at 17:35
  • You also need to check if the user has rx permissions on all parent directories all the way back to the root dir. This is something that catches out a lot of users running web servers - if the web server user (e.g. www-data) can't traverse the path to the file, then it can't access the file no matter what the file perms are. The same is true for other users. – cas Mar 15 '16 at 22:40
  • @becko Yes, that is correct. – Dmitry Grigoryev Mar 16 '16 at 07:24
  • @Otheus That would mean you'd have to chmod o+rwx a file before you could provide ACL permissions to it. Should the filesystem be mounted without ACL for some reason, that file would be accessible by anyone. – Dmitry Grigoryev Mar 16 '16 at 07:49
  • @cas You'll also need to check if the filesystem is read-only or not, whenever the user is root, whenever CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH are effective etc. etc. – Dmitry Grigoryev Mar 16 '16 at 07:56
  • @cas Ok, so there seem to be a lot of specific cases. Is the complete algorithm, including all special cases, explained somewhere? – a06e Mar 16 '16 at 08:19
  • @DmitryGrigoryev your reasoning is correct, and that is why I think ACLs on Linux are broken. I was unable to grant specific users to view files unless the file had o+r AND the ACL was enabled. – Otheus Mar 16 '16 at 12:18