Take the 2-minute tour ×

Can some one please explain with a an example the file permission mechanism in Linux and other Unix like systems ? What are the nine bits for ? Why do we have a group id for a user as well as for a file ? Are these two related ?

share|improve this question
There are more than the nine bits you see. linux.die.net/Linux-CLI/file-permissions.html –  ott-- Dec 7 '12 at 9:41

1 Answer 1

up vote 2 down vote accepted

The ownership and access permissions basically work together. Ownership tells the system who can access the file, the file permissions say how.

Ownership splits access into three groups: user (a single user owning the file), group (of users), others (the rest of the world).

The permissions are: r - reading is allowed, w - writing is allowed, x - executing is allowed

For directories the meaning is slightly different: x allows you to enter a directory, while r listing its contents (and w lets you update it) - that means, that if you know the exact file name you don't need read permissions on the directory it resides in, x is enough. You need r on the file though.

Then there is one additional bit triplet: setuid, setgid, sticky. The first two cause (on an executable file) the program to be run as the user/group owning the file (depending on which of the two bits are set). Sticky bit is implementation dependent. For executables it used to mean that the program code should be cached in swap to speed up loading it next time. For directory it prevents unprivileged users removing a file if they do not own it, even if they had the rights to do so otherwise - this is why it is usually set on world writeable directories like /tmp.

In addition to this, many filesystems support additional access control lists (ACL) which allow finer grained access control. These are accessible with getfacl/setfacl rather than with chmod.

As a side note, similar permission system is usually implemented for memory (RAM) with page granularity. The main aim is to adhere to the "W^X" principle: either you can write to the memory or you can execute it, but not both at the same time. While generally a good idea, it doesn't work for interpreted just-in-time compiled code - e.g. Java, because the interpreter needs to compile/optimize the generated code (i.e. to write the page) and then execute it, often incrementally (and changing the permissions every time wouldn't make much sense).

share|improve this answer
Note that chmod/ls are used to handle ZFS acls on Solaris, not setfacl/getfacl. –  jlliagre Dec 7 '12 at 14:26

Your Answer


