Unix/Linux permissions are shown with "ls -l":

total 154
drwxr-xr-x   2 root  sys          512 Apr  1 07:39 dir
-rw-r--r--   1 root  sys         3515 Mar  6 13:28 disks.html
-rw-r--r--   3 root  sys         7154 Mar  6 13:28 floppies.html
-rw-r--r--   3 root  sys         7154 Mar  6 13:28 floppy.html
-rw-r--r--   1 root  sys         3480 Mar  1 05:11 hardware.html
-rw-r--r--   1 root  sys         1322 Mar  6 13:28 index.html
-rw-r--r--   1 root  sys         7942 Mar  6 13:28 scripting.html

Note: these are classic Unix permissions. However, many modern Unixes support extended attributes that go beyond this. We'll look at one example of that later in the article. You also need to know that Unix and Windows permissions don't map well to each other, so if you are using something like Samba or Visionfs , you need to understand how permissions will be shown and honored. Some examples of that are shown later.

To interpret permissions, you need to pay attention to both the permissions themselves (the "-rw-r--r--" above) and the ownership information ("root" and "sys" for the files above).

The very first part of the permissions tells you whether what you are seeing is an ordinary file, a directory, or something else:

brw------- 1 root sys 1, 0 Feb 13 09:22 bdevfile
crw-r--r-- 1 root sys 2, 1 Apr 1 07:41 cdevfile
prw-r--r-- 1 root sys 0 Apr 1 07:42 namedpipe
srw-r--r-- 1 root sys 0 Apr 1 07:50 semaphore
mrw-r--r-- 1 root sys 0 Apr 1 07:50 sharedmem
lrwxrwxrwx 1 root sys 11 Apr 1 07:47 symlink -> /etc/passwd

Another way to find out what you are looking at is to use the "file" command. For example, "file *" on the directory we have here produces:

bdevfile:       block special (1/0)
cdevfile:       character special (2/1)
dir:            directory
disks.html:     ascii text
floppies.html:  ascii text
floppy.html:    ascii text
hardware.html:  ascii text
index.html:     ascii text
namedpipe:      fifo
perms.html:     ascii text
scripting.html: ascii text
semaphore:      Xenix semaphore
sharedmem:      Xenix shared memory handle
symlink:        ascii text

Note that "file" tells you what the target of "symlink" is rather than just identifying it as a symbolic link.

Who can access ?

The rest of the permissions show what restrictions are in place depending upon who accesses the file. The owner of the file ("root" in all the examples shown so far) is controlled by the next three characters, users in the group ("sys" above) are affected by the next three bytes, and the last three affect everyone else: in the examples above, if you are not "root" and don't belong to the group "sys".

The characters shown by "ls" are really represented by bits in the file's inode. In the text below, I sometimes refer to (for example) the "group execute bit" rather than the execute permission.

You will mostly see permissions as combinations of "rwx". Let's look at some examples of those before seeing the oddities:

-rwx-r-x---  1 tom     acct         7538 Dec  9 08:48 execfile

The "execute" permission needs some explanation for those from the Windows world: Unix programs don't use extensions like "bat" or "exe" to be executable- instead, the "x" permissions settings determines this. Of course, the file still has to be a legitimate program- but a legitimate program will not run until it is marked as "x".

This file is owned by tom, and has the group ownership of "acct". The owner (tom) has full permissions- he can read this file (display it, read it into an editor, copy it somewhere else), write it (replace its contents with something else), and execute it.

Anyone in the group "acct" can read and execute it, but can't write it.

Anyone else can't do anything.

The "id" command (most Unix/Linux) will show you what groups you belong to:

uid=201(apl) gid=50(group) groups=50(group),79(acct)

Note that "apl" is a member of "acct", but that his login or primary group is "group". On older Unixes, you might have had to use the "newgrp" command to actually make use of anything other than your login group membership. That's usually not true today; the "apl" user would be able to execute "execfile" above without running "newgrp acct" first. However, there are conditions where that won't be true, because there is also a kernel imposed limit on your supplemental group membership. For example, on SCO OSR5, the NGROUPS parametr is set to 8 by default, which means that if you belong to more than 8 groups, only the first 8 will be listed by "id" or "sg". In that case, "apl" might be a member of "acct", but belong to too many other groups for it to be included automatically. If that were the case, apl would have to "newgrp acct" first. That would change apl's primary group to "acct". Or, apl could use "sg" to specify a new list of supplemental groups.

Bruce Garlock provided the relevant Linux information:

Tony - I actually researched this at one point, and found out that the max under Linux is 32. Here is a link to a relevant question about this:


Permissions on directories can be a little confusing. Read permission ("r") means that you can list the directory- for example, use "ls" on it. But that's all it means: if you only have read permission, you can't cd to that directory, you can't copy files into that directory, and you can't even do an "ls -l" on it. Note that it doesn't help if files or directories under that would be accessible by you: you won't be able to get to them. Write permission ("w") allows you to create new files and to remove files. Normally, write permission is all you need to remove a file- you might not have any permissions on the file itself, but if you have write permission on the directory and the text bit is not set (see below) you will be able to remove the file whether or not you have any permissions on the file itself, and no matter who owns it. However, you will need at least "x" permission also, because "x" is what lets you "search" a directory. You might also think of it as "use its contents". You need "x" permissions on the directory to read a file in that directory, to copy it elsewhere and (as noted above) to delete it.

Special permissions

In addition to the "rwx" permissions, you may see s,S, t and T. The "t" bit is seen at the end of a directory or file:

drwxr-xr-t   3 apl      sys          512 Apr  1 10:45 dir
-rw-rw---T   1 root     lp            59 Apr  1 08:40 tfile

If it's upper case, that just means that there is no execute permission hidden by the "t"- if lower, there is. For example:

# ls -l t
-rw-rw---T   1 root     lp            59 Apr  1 08:40 t
# chmod +x t
# ls -l t
-rwxrwx--t   1 root     lp            59 Apr  1 08:40 t
# chmod -x t
# ls -l t
-rw-rw---T   1 root     lp            59 Apr  1 08:40 t

The same is true for "s"- if it's "S", there's no underlying execute permission. But what do these indicate? Well, if the file is a directory, then the "t" setting means that owners of files in that directory can delete those files that they own, but not anyone else's. This setting is often used for temporary directories like /tmp: anyone can create files there, but you can only remove your own files (unless, of course, your are root).

For an ordinary file, "t" represents the "sticky" or "text" bit. A capital "T" (no underlying execute bit) is meaningless- no effect on the file at all (but see the Samba notes later). For an executable file marked this way ("t"), the executable image is supposed to be "sticky" in memory- in other words, the system should not reuse the memory used by the program. You'll often see "vi" marked this way, the assumption being that vi is a commonly used program and as sych should be readily available. Of course, on a typical Unix system nowadays, many of the users never even see the shell, never mind use vi, so this may not make much sense. Some OS'es (FreeBSD for one) totally ignore the sticky bit on anything but directories.

The "s" bit on the group set of a directory (e.g. rwxr-srx) causes new files created in that directory to have the same group ownership as the directory rather than the group id of the user or process creating the file.

An "s" on an executable can be seen either on the owner set or the group set, or both:

---x--s--x   1 bin      auth       63612 Jul 28  2000 /bin/passwd

This is the "setuid" flag- if you have permission to execute the program (for example, anyone has permission to execute /bin/passwd), you end up having the effective id or effective group id of the file while the program runs. Executing /bin/passwd, for example, means that you temporarily have the same group privileges as "auth" on this SCO system- because the "s" is set on the group permissions. Note that this Red Hat 7 Linux system does it differently:

-r-s--x--x   1 root     root       13536 Jul 12  2000 /bin/passwd

The effect is the same, only this time the user gets root's permissions. This is used to give access to files that the user ordinarily has no access to. In the case of "passwd", the /etc/passwd ( or /etc/shadow) and related files need to be written, which an ordinary user would not be able to do- but with the help of the setuid flag, they can. This same trick is sometimes used with databases; the ubiquitous (on SCO systems) Filepro database runs setuid.

Extended attributes

Some modern Unixes (Linux, UW, and others) have extended the permissions model. This requires new commands, and may be limited to certain types of filesystems. For example, on Red Hat Linux 7, the "chattr +i file" command makes "file" unchangeable and not able to be deleted: "immutable", even by its owner (the owner can, of course, "chattr -i file" to undo this). "lsattr" lists perms. This can really help in preventing accidental removal of files, but it can be very confusing for users who aren't even aware that such attributes exist. Mac OS X and BSD systems add a "system immutable" bit, which, once set, can only be undone in single user mode. On other Unixes, these types of things may be handled by "setacl" commands; check your man pages for details ("man acl" on Linux). Sometimes there can be multiple levels: Mac has both chflags and SetFile, which do different things. SCO added acl capability with OpenServer 6

Other Systems

Unix systems often have the ability to present their file systems in some format that other systems can read. For example, Samba is very commonly used to present Unix file systems in Windows Network Neighborhood. Unfortunately, Unix and Windows have different ideas about permissions, so presenting a consistent view of files is often difficult. Windows has Read-Only, System, Hidden and Archive attributes for files, and the only one that maps at all to Unix is Read-Only. The rest have no Unix equivalent, but obviously if the Unix system is going to store Windows files, Samba needs to provide that capability. It does so by using the execute bits (which are unused by Windows). Therefore, a Windows file with its Archive bit set will have the owner executable bit set on the Unix side. A Windows System file would have the group execute turned on, and finally the Hidden attribute can be represented by the "other" execute bit (I say "can be" because System and Hidden mapping is often turned off in Samba).

On Mac OS X a file can be invisible because it's listed in /.hidden OR because its attribute (/Developer/Tools/GetFileInfo -a filename) is V.

Some of the files are both, so you'd need to use /Developer/Tools/SetFile to change them to v AND remove them from /.hidden and then restart Finder.

Changing Permissions

There are two ways to use "chmod" to change permissions. You can be specific, and use octal numbers, or you can use symbolic modes. The octal method requires understanding the bits actually set in the inode. The "r" has the value of 4, "w" is two, and "x" is "1". Therefor to set a file to "rwxrw-r-x" (an odd permission, just used for example), you'd do:

chmod 765 file

To make it "rwx------", you'd use "chmod 700", and "rw-r--r--" would be "chmod 644".

You can also set the setuid bit this way:

chmod 4755 file

sets "rwsr-xr-x" and "chmod 2755" sets "rwxr-sr-x". A "chmod 1711" sets "rwx--x--t".

But what do you do when you don't want to change thing everything, but just want to add or subtract a certain permission? This can be particularly important when you are applying new permissions to large numbers of files with wildcards or recursively (chmod -R). This is where the symbolic modes are handy (the symbolic modes are also good if you just can't get used to the octal numbers). Using symbolic mode, you could add group execute permission to files with "chmod g+x". That wouldn't affect any other permissions, not even any group permissions except the "x". See "man chmod" for more examples.

Using Umask

Your "umask" setting (just type "umask" to see yours) determines what permissions newly created files will have. As with chmod, you can use the octal numbers or symbolic permissions, but the meaning is different. With the octal mode, you specify the bits you don't want set, but with symbolic you actually specify what you want. Well, almost- except for directories, you really only get to control the read and write bits. A few examples might help clarify this:

By default, most systems set umask to 022 or u=rwx,g=rx,o=rx (symbolic). This means that new files will be created without write permission except for the owner. Directories will get "x" permission across the board, but ordinary files will not. Therefore, ordinary files will end up with "rw-r--r--" and directories will be "rwxr-xr-x". If you wanted to add group wite permission for new files, you could do either "umask 002" or "umask u=rwx,g=rwx,o=rx".

Keep in mind that umask is NOT forcing these permissions. It is masking, so it turns OFF the bits you don't want set. If a program specifies certain permissions (without resetting umask), it gets what it asks for, minus the bits you turned off. For example, if a program wanted to set 660 perms and the umask is 002, the file will have 666 permissions. If it set 666, the file would be 664, and 664 would also be 664. Also: most programs that want to set a specific permission simply change umask to 000 before creating the file, so they get exactly what they want.

For a fascinating and at times funny exploration of the kernel CMASK setting in SCO Unix, see OSR 507: umask, configuration and default settings, where Bela Lubkin chases umask through every step, noting the errors in documentation and by the programmers who believed it! A fun read..

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Understanding Unix and Linux Permissions


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Tony Lawrence

Fri Feb 25 00:34:29 2005: 69   theorem

so, lets say I want to give a whole group of users 775 permissions when defaultly writing in a directory (add/modify/etc), but not make it global for all users on the system.

Would I umask ? How could I get this done ? Would I use setuid bits on the directory in question to allow the group to share the work (775). ?

Thanks. please email theorem21 at hotmail . com

Fri Feb 25 00:53:05 2005: 71   TonyLawrence

You'd have to set the mask for those users. I'd do it in /etc/profile with a conditional statement.

Thu May 19 23:26:04 2005: 552   anonymous

I believe, in your example near the bottom, "rw-r--r--" should be 644, NOT 611.


Thu May 19 23:50:41 2005: 553   TonyLawrence

Oops, thanks.. will fix it.

Tue Oct 17 00:20:21 2006: 555   BigDumbDinosaur

No way... LOL

Tue Oct 17 13:29:42 2006: 2527   BigDumbDInosaur

Tony, the comment right above this one was not posted by me. Apparently there's an imposter lurking in the swamp. <Grin>

Tue Oct 17 13:38:12 2006: 2528   TonyLawrence

Obviously - the key doesn't match.

I don't know what he's LOL'ing about anyway :-)

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us