File Permissions

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?

Answer

Sometimes.

If you have write permission on the directory you can remove the file from that directory. If that is the last link to the file then the file will be deleted.

Try it from a shell. Your shell might query the action (in case it was an inadvertent mistake) but will do it.

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

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Filing System

"Everything is a File" • FAT • File Access • File Attributes • File Descriptor • File Locking • File Permissions • File Systems • File Types • Files • Filing System • Filing System Implementation • Fragmentation • I-nodes • Journalling File System • Links • Network File System (NFS) • Resources

Articles on Security

Buffer Overflow • Containers • Context • Disk Partition • File Attributes • File Permissions • Journalling File System • Mutual exclusion • Processor Privilege • SETUID • Security

Articles on User

"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals