I'llI’ll answer your questions in three parts: file types, permissions, and use cases for the various forms of chmod.
The first character in ls -l output represents the file type; d means it'sit’s a directory. It can'tcan’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'reyou’re likely to come across are
-: "regular"“regular” file, created with any program which can write a fileb: block special file, typically disk or partition devices, can be created withmknodc: character special file, can also be created withmknod(see/devfor examples)d: directory, can be created withmkdirl: symbolic link, can be created withln -sp: named pipe, can be created withmkfifos: socket, can be created withnc -UD: door, created by some server processes on Solaris/openindiana.
suid,sgidand "sticky"“sticky” (see below)- user permissions
- group permissions
- "other"“other” permissions
- "read"“read” is 4
- "write"“write” is 2
- "execute"“execute” is 1
suidis 4; binaries with this bit set run as their owner user (commonlyroot)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'sit’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'sdirectory’s owner group by default (this is handy for creating shared folders)- "sticky"“sticky” (or "restricted deletion"“restricted deletion”) is 1; files in directories with this bit set can only be deleted by their owner, the directory'sdirectory’s owner, or
root(see/tmpfor a common example of this).
See the chmod manpage for details. Note that in all this I'mI’m ignoring other security features which can alter users'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 behaviousbehaviour 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'sit’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 u-s, g-s and/or o-t explicitly or specify a negative numeric value, so chmod -7000 will clear all the special bits on a directory.
In ls -l output, suid, sgid and "sticky"“sticky” appear in place of the x entry: suid is s or S instead of the user'suser’s x, sgid is s or S instead of the group'sgroup’s x, and "sticky"“sticky” is t or T instead of others'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.
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'sIt’s useful when you want to set special bits as well as permission bits; otherwise the bits are cleared if you'reyou’re manipulating a file, preserved if you'reyou’re manipulating a directory. So chmod 2750 ensures you'llyou’ll get at least sgid and exactly u=rwx,g=rx,o=; but chmod 0750 won'twon’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'reyou’re used to using numeric modes, it'sit’s often easier to just specify the full mode that way; and it'sit’s useful to be able to think of permissions using numeric modes, since many other commands can use them (install, mknod...).
