I’ll answer your questions in three parts: file types, permissions, and use cases for the various forms of
The first character in
ls -l output represents the file type;
d means it’s a directory. It can’t be set or unset, it depends on how the file was created. You can find the complete list of file types in the ls documentation; those you’re likely to come across are
-: “regular” file, created with any program which can write a file
b: block special file, typically disk or partition devices, can be created with
c: character special file, can also be created with
d: directory, can be created with
l: symbolic link, can be created with
p: named pipe, can be created with
s: socket, can be created with
D: door, created by some server processes on Solaris/openindiana.
chmod 0777 is used to set all the permissions in one
chmod execution, rather than combining changes with
u+ etc. Each of the four digits is an octal value representing a set of permissions:
sgidand “sticky” (see below)
- user permissions
- group permissions
- “other” permissions
The octal value is calculated as the sum of the permissions:
- “read” is 4
- “write” is 2
- “execute” is 1
For the first digit:
suidis 4; binaries with this bit set run as their owner user (commonly
sgidis 2; binaries with this bit set run as their owner group (this was used for games so high scores could be shared, but it’s often a security risk when combined with vulnerabilities in the games), and files created in directories with this bit set belong to the directory’s owner group by default (this is handy for creating shared folders)
- “sticky” (or “restricted deletion”) is 1; files in directories with this bit set can only be deleted by their owner, the directory’s owner, or
/tmpfor a common example of this).
chmod manpage for details. Note that in all this I’m ignoring other security features which can alter users’ permissions on files (SELinux, file ACLs…).
Special bits are handled differently depending on the type of file (regular file or directory) and the underlying system. (This is mentioned in the
chmod manpage.) On the system I used to test this (with
coreutils 8.23 on an
ext4 filesystem, running Linux kernel 3.16.7-ckt2), the behaviour is as follows. For a file, the special bits are always cleared unless explicitly set, so
chmod 0777 is equivalent to
chmod 777, and both commands clear the special bits and give everyone full permissions on the file. For a directory, the special bits are never fully cleared using the four-digit numeric form, so in effect
chmod 0777 is also equivalent to
chmod 777 but it’s misleading since some of the special bits will remain as-is. (A previous version of this answer got this wrong.) To clear special bits on directories you need to use
o-t explicitly or specify a negative numeric value, so
chmod -7000 will clear all the special bits on a directory.
ls -l output,
sgid and “sticky” appear in place of the
S instead of the user’s
S instead of the group’s
x, and “sticky” is
T instead of others’
x. A lower-case letter indicates that both the special bit and the executable bit are set; an upper-case letter indicates that only the special bit is set.
The various forms of chmod
Because of the behaviour described above, using the full four digits in
chmod can be confusing (at least it turns out I was confused). It’s useful when you want to set special bits as well as permission bits; otherwise the bits are cleared if you’re manipulating a file, preserved if you’re manipulating a directory. So
chmod 2750 ensures you’ll get at least
sgid and exactly
chmod 0750 won’t necessarily clear the special bits.
Using numeric modes instead of text commands (
[ugo][=+-][rwxXst]) is probably more a case of habit and the aim of the command. Once you’re used to using numeric modes, it’s often easier to just specify the full mode that way; and it’s useful to be able to think of permissions using numeric modes, since many other commands can use them (
Some text variants can come in handy: if you simply want to ensure a file can be executed by anyone,
chmod a+x will do that, regardless of what the other permissions are. Likewise,
+X adds the execute permission only if one of the execute permissions is already set or the file is a directory; this can be handy for restoring permissions globally without having to special-case files v. directories. Thus,
chmod -R ug=rX,u+w,o= is equivalent to applying
chmod -R 750 to all directories and executable files and
chmod -R 640 to all other files.
So, permissions in Linux are very important. I will try to make a short explanation.
For pieces of a file mode
Every Unix file has a set of permissions that determine whether you can read, write, or run the file. Running
ls -l displays the permissions. Here’s an example of such a display:
-rw-r--r-- 1 user somegroup 7041 Mar 26 19:34 somefile
I attach a image of pieces of a file mode:
Type can be different thing. For example:
- d (directory)
- c (character device)
- l (symlink)
- p (named pipe)
- s (socket)
- b (block device)
- D (door, not common on Linux systems, but has been ported)
If you want to set some permissions for all directory you can use R attribute, for example:
chmod -R 777 /some/directory/
For chmod 777 vs 0777
chmod command usually expects the input to be an octal number, the leading zero refers to the value of the sticky/sgid/suid bit triplet. In C however, it would make a difference, since
777 would be translated to
01411 (octal), thus setting the sticky bit (see the
chmod(2) man page), read permissions for owner and executable bit for group and others (which is a rather strange combination).
I found other picture about Linux permissions and I will attach to understand more easy:
d means it is a directory, if you have a file it is
- and if it is a link you will find an
l. It can’t be set/unset.
If you use 0777 as permissions you are giving full control (read+write+execute) to every user/group of the system. It is a lazy way to solve problems when you have users/groups that can’t access directories/files.
For example, if you list the content of a directory and get this:
-rw-r--r-- 1 root root 42596 jun 7 2012 preloadable_libintl.so
preloadable_libintl.so is a file owned by user root and group root. The owner has read and write access, the group has only read access and any other user has read access. This can be translated as 644.
If I change it to 777 it will look like this:
-rwxrwxrwx 1 root root 42596 jun 7 2012 preloadable_libintl.so