The "proper" way to achieve this would be ACLs, which means following the answer provided by HBruijn.
However, that is not to say it is impossible to solve this using traditional Unix file permissions. Without using ACLs, the same goal can be achieved as follows:
- Make the file owned by a group
read-only-users
.
- Place the user(s) who should have read-only access into the
read-only-users
group.
- Set permissions of the file to
757
.
Why does this work?
Unix file permissions are not evaluated so that the most permissive wins, but according to the file's class. This means user(s) in a particular file class have distinct permission sets:
Owner file class - if the owner performs an action, his/her operation is evaluated against the owner permission mode bits (first digit in the bitmask).
Group file class - if a user is not the file owner, but is otherwise a member of the file's group, the effective permissions governing that operation are the group permission mode bits (second digit in the bitmask).
Other file class - if a user is neither the file owner, nor a member of the file's group, the other permission mode bits apply (third digit in the bitmask).
In this instance, we give the file a distinct group to which we add read-only users. When permissions are evaluated, members of that group are restricted to the group permission bitmask, which expressly prohibits writing to the file. This achieves the stated objective.
Caveat - file owner
For obvious reasons, you cannot lock down the file owner using this technique. The permissions assigned to the owner will always take precedence over group permissions, even if the owner is a member of read-only-users
. In any case, even if you do restrict the owner, on a standard Unix system, they will always have the ability to call chmod(1)
to give themselves permission, irrespective of what their current bitmask is.