The passwd
program has the setuid bit set, which you can see with ls -l
:
-rwsr-xr-x 1 root root 39104 2009-12-06 05:35 /usr/bin/passwd
It's the s
(the fourth character of the line).
All programs that have this permission bit set run as the owner of that program. In this example, the user is root
(third word of the line).
These setuid programs need to make sure that they don't damage anything, since every user of the system can run them with effective root privileges. That's why you can only change your own password. Linux and other similar operating systems are still secure because the authors of these setuid programs take a lot of care.
See for example suexec.c from the Apache Web Server, which is a popular setuid program. There are unusually many comments in that source code.
I’ll answer your questions in three parts: file types, permissions, and use cases for the various forms of chmod
.
File types
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 mknod
c
: character special file, can also be created with mknod
(see /dev
for examples)
d
: directory, can be created with mkdir
l
: symbolic link, can be created with ln -s
p
: named pipe, can be created with mkfifo
s
: socket, can be created with nc -U
D
: door, created by some server processes on Solaris/openindiana.
Permissions
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:
suid
, sgid
and “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:
suid
is 4; binaries with this bit set run as their owner user (commonly root
)
sgid
is 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
root
(see /tmp
for a common example of this).
See the 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 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” appear in place of the x
entry: suid
is s
or S
instead of the user’s x
, sgid
is s
or S
instead of the group’s x
, and “sticky” is t
or 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 u=rwx,g=rx,o=
; but 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 (install
, mknod
...).
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.
Best Answer
To add Eric's answer (don't have rep to comment), permissions are not stored in file but file's inode (filesystem's pointer to the file's physical location on disk) as metadata along with owner and timestamps. This means that copying file to non-POSIX filesystem like NTFS or FAT will drop the permission and owner data.
File owner and group is just a pair of numbers, user ID (UID) and group ID (GID) respectively. Root UID is 0 as standard so file will show up as owned by root on (almost) every unix-compliant system. On the other hand, non-root owner will not be saved in meaningful way.
So in short, root ownership will be preserved if tarball'd or copied via extX usbstick or the like. Non-root ownership is unreliable.