When we set setuid to a file, we do the following in the terminal:
chmod u+s filename This works fine. But the octal number 4000 is always associated with setuid (in books etc).
I understand (to some good extent) file permissions, the concept of umask, setuid and using octal numbers with chmod. But I still cannot figure out the relationship between the octal number 4000 and setuid. Please explain.
It's just a convention. All constant identifiers are associated with numbers in the Linux source code. Some of them are very old, and come from the very first releases of the kernel while others were added recently.
The constant S_ISUID associated with "setuid" is defined in include/uapi/linux/stat.h, one of the numerous Linux headers. It could have been defined to anything but it happened to be 04000.
As stated by @steeldriver, man 2 stat can help you understand the meaning of the different constants used for files permission:
S_IFMT 0170000 bit mask for the file type bit fields S_IFSOCK 0140000 socket S_IFLNK 0120000 symbolic link S_IFREG 0100000 regular file S_IFBLK 0060000 block device S_IFDIR 0040000 directory S_IFCHR 0020000 character device S_IFIFO 0010000 FIFO S_ISUID 0004000 set-user-ID bit S_ISGID 0002000 set-group-ID bit (see below) S_ISVTX 0001000 sticky bit (see below) S_IRWXU 00700 mask for file owner permissions S_IRUSR 00400 owner has read permission S_IWUSR 00200 owner has write permission S_IXUSR 00100 owner has execute permission S_IRWXG 00070 mask for group permissions S_IRGRP 00040 group has read permission S_IWGRP 00020 group has write permission S_IXGRP 00010 group has execute permission S_IRWXO 00007 mask for permissions for others (not in group) S_IROTH 00004 others have read permission S_IWOTH 00002 others have write permission S_IXOTH 00001 others have execute permission In this excert, you see not only the constants and their numeric value but also the way they are chosen. Developers/designers have chosen the constants in such a way you can combine them. For example S_ISUID and S_IRWXU and S_IRUSR and S_IRGRP = 04740, so permission 04740 precisely means "setuid and all permissions for owner and read permission for owning group".
man 2 stat has a discussion of the stat structure and its fields (in particular, the st_mode value) - slightly more convenient than trawling the header file. man 2 stat which lists these values. The Linux kernel source contains the values without explanation, and Some man pages give an explanation for some of the values. This is a great compilation of info, but is there an actual reference or manual for this somewhere that isn't behind a POSIX paywall? In most Unix-like systems, a file, directory, or any other filesystem object is represented by an inode, which contains, among other things, an integer called the mode, which describes the type of object and some of its permissions. It's described in POSIX stat.h.
The following symbolic names for the values of type mode_t shall also be defined: File type: S_IFREG Regular. S_IFDIR Directory. S_IFLNK Symbolic link. File mode bits: S_IRWXU Read, write, execute/search by owner. S_IRUSR Read permission, owner. S_IWUSR Write permission, owner. S_IXUSR Execute/search permission, owner. ... S_ISUID Set-user-ID on execution. S_ISGID Set-group-ID on execution. ... Those are all symbolic names for integer constants. S_IFREG is 0100000. S_IRUSR is 000400. S_ISUID is 004000. They're in octal for ease of use: the file mode bits can logically be considered to be 4 groups of 3 bits each.
Here you can see the file type bits and file mode bits of my .profile:
$ perl -e 'printf("%#o\n", (stat(".profile"))[2]);' 0100644 Users can set the mode bits (but not the file type) using the chmod system call, which takes an integer argument (possibly using some of those S_* symbolic constants), or the chmod utility, which takes either an integer or symbolic names (such as u+r).
Since, in practice, there are not that many different combinations of mode bits, many Unix users over many decades have called chmod (both the system call and the command) with a numeric argument rather than symbolic names. 0755 means "writable by owner, readable and executable to everyone else", 0644 means "writable by owner, readable by everyone else", 04755 means "setuid, writable by owner, readable and executable by everyone else`.
From the (english) man page for chmod (debian jessy): (Highlight by me)
A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros. The first digit selects the set user ID (4) and set group ID (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who owns the file: read (4), write (2), and execute (1); the third selects permissions for other users in the file's group, with the same values; and the fourth for other users not in the file's group, with the same values.
I am not sure if this answers your question, but it does explain what the numbers mean.
You can go through this link for more details about setuid setgid and sticky bit.
Setuid, Setgid and Sticky Bits are special types of Unix/Linux file permission sets that permit certain users to run specific programs with elevated privileges. Ultimately the permissions that are set on a file determine what users can read, write or execute the file. For the special permissions, you prepend these numbers with another number where 4 is setuid, 2 is setgid, and 1 is the sticky bit. The following commands are all the same.
root@host [~]# chmod 4755 myfile root@host [~]# chmod u+s myfile root@host [~]# ls -l myfile -rwsr-xr-x 1 test test 0 Mar 2 17:59 myfile root@host [~]# root@host [~]# chmod 2755 myfile root@host [~]# chmod g+s myfile root@host [~]# ls -l myfile -rwxr-sr-x 1 test test 0 Mar 2 17:59 myfile root@host [~]# root@host [~]# chmod 1755 mydir root@host [~]# chmod +t mydir root@host [~]# ls -ld mydir drwxr-sr-t 2 test test2 4096 Mar 2 19:59 mydir root@host [~]# 
chmod 4755 myfile chmod u+s myfile When I was first learning, this both helped me to understand this quickly.