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.
Unix/Linux permissions are shown with “ls -l”:
To interpret permissions, you need to pay attention to both the permissions themselves (the “-rw-r–r–” below) and the ownership information (“root” and “sys” for the files below).
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
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
Who can access ?
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”i rather than the execute permission.
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”.
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:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0010.0/0788.html
Directories
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). 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. Sometimes there can be multiple levels: Mac has both chflags and SetFile, which do different things.
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).
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 611”.
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.
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
