File Permissions
| On path: Filing | 1: Filing System • 2: File Systems • 3: Files • 4: File Attributes • 5: File Types • 6: File Permissions • 7: File Access • 9: Filing System Implementation • 10: I-nodes • 11: Links • 12: File Descriptor |
|---|
| Depends on | File Attributes • Files • Security |
|---|
Most file systems include some form of access control. In the simple case, this could support multiple users of a system so that each user’s files were private. On its own, this would be rather primitive because it would imply that every user needed a separate copy of every application program etc.
Unix-like systems typically have three classes of file access permission which, combined with other information, provide reasonably flexible access control. These are part of a file’s attributes. The relevant information is:
- The file’s owner (UID).
- The file’s group (GID).
- The access permissions in terms of permitted {read, write, execute} for
- the owner
- members of the group
- any system user
For a regular file:
- read permission allows the appropriate clients to see the content of the file.
- write permission allows the appropriate clients to change the content of the file.
- execute permission allows the appropriate clients run the file as code.
- This includes execution of a binary file and a text file in the case of a shell script.
Permissions for a directory are similar although:
- execute permission allows the user to follow the links in a directory – e.g. to sub directories.
It is possible to follow through an ‘executable’ directory even if it is not readable.
Groups are defined in a system file, which itself should only be writeable by ‘root’ to keep the system secure. They allow a group of users access to particular space so they can work together whilst excluding the ‘general public’. An obvious example in a university would be each research group maintaining some shared but exclusive resources.
File permissions have a similar function to memory access permissions, providing not only security against intrusion but also safety against accident. The usual general applications binaries will probably be owned by root – or some other non-usual UID – and not be writeable by anyone else, thus they can be read and executed but not deleted. Write-protecting files is often a good safety strategy. Similarly, files such as photographs can be set so no one will (successfully) attempt to execute them!
In Unix, one way to see a file’s permissions is to use ls -ls which reveals an amalgamation of type and permission information. The permission looks something like these examples:
-rwx------ Owner has read, write and execute permission; no one else has any permission.
-rw-r----- Owner has read and write permission; group member can only read.
-r-xr-xr-x Anyone can read or execute the file; no one can write to it.
umask
In Unix(-like) file systems there is a default set of file permissions for files created by each process. This is called umask. The umask setting is inherited from parent processes (such as a shell) but can subsequently be altered locally. The value prevents the specified file permission bits from being set.
For example, umask 077 will prevent any access except by the file owner; umask 022 will (potentially) allow general access except for write access other than by the file owner.
You can try this from a shell. The umask command on its own reads the current setting; with an argument it writes a new setting.
Question
In a Unix file system, is it possible to delete a file if you don’t have write permission?
Access control lists
A more sophisticated means of controlling file (and other) permissions is an Access Control List (ACL); this is a feature in the latest Windows and some Unix file systems. Such a list contains entries which specify the permissions of (in this case) file access for each file for each user, allowing more selective permission control than single groups. The list is referenced by the filing system to allow or deny access to that file.
Access control may offer other features, such as logging access to a file for audit and security purposes. It can then be possible to track everyone looked at or changed a file and when. This is usually only important when dealing with sensitive data, although data protection is currently a ‘hot’ topic.
As well as files, similar access control may be used in, for example, databases. Note that a database probably doesn’t have a separate file for every ‘item’ (whatever that is) which it stores [Why would that be a bad idea?] so an access control list gives more flexibility than simple file/user/group access.
Role-based Access
Role-based access control takes a slightly different approach this allows particular individuals to do particular things to a record. Thus you might be allowed to modify certain fields of a record, only read others and not see some at all. (Think of personal medical records, for example.) This gives rather more ‘fine-grain’ control … but we’re wandering away from O.S. file permissions here.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 13.4, pages 550-555 |
|---|
