The thing is, I always thought these permissions collapse on each other, starting with the most general one (other -> group -> user).
If it was the case then “other” permissions would apply to everyone.
In other words, if o=rwx who cares what the persmissions for group and user are?
That's different from your previous sentence. Here you're implying that the permissions are or'ed together, e.g. that userX has the read permission if userX owns the file and the file is user-readable, or if a group that userX belongs to owns the file and the file is group-readable, or if the file is other-readable. But that's not how it works. In fact, o=rwx
means that the rwx
permissions apply to others, but it doesn't say anything about entities that are not others.
First, it doesn't directly matter which groups a user belongs to. The kernel doesn't have a notion of users belonging to groups. What the kernel maintains is, for every process, a user ID (the effective UID) and a list of group IDs (the effective GID and the supplementary GIDs). The groups are determined at login time, by the login process — it's the login process that reads the group database (e.g. /etc/group
). User and group IDs are inherited by child processes¹.
When a process tries to open a file, with traditional Unix permissions:
- If the file's owning user is the process's effective UID, then the user permission bits are used.
- Otherwise, if the file's owning group is the process's effective GID or one of the process's supplementary group ID, then the group permission bits are used.
- Otherwise, the other permission bits are used.
Only one set of rwx bits are ever used. User takes precedence over group which takes precedence over other. When there are access control lists, the algorithm described above is generalized:
- If there is an ACL on the file for the process's effective UID, then it is used to determine whether access is granted.
- Otherwise, if there is an ACL on the file for the process's effective GID or one of the process's supplementary group ID, then the group permission bits are used.
- Otherwise, the other permission bits are used.
See also Precedence of ACLS when a user belongs to multiple groups for more details about how ACL entries are used, including the effect of the mask.
Thus -rw----r-- alice interns
indicates a file which can be read and written by Alice, and which can be read by all other users except interns. A file with permissions and ownership ----rwx--- alice interns
is accessible only to interns except Alice (whether she is an intern or not). Since Alice can call chmod
to change the permissions, this does not provide any security; it's an edge case. On systems with ACLs, the generalized mechanism allows removing permissions from specific users or specific groups, which is sometimes useful.
Using a single set of bits, rather than or-ing all the bits for each action (read, write, execute), has several advantages:
- It has the useful effect of allowing removing permissions from a set of users or groups, on systems with ACLs. On systems without ACLs, permissions can be removed from one group.
- It is simpler to implement: check one set of bits, rather than combining several sets of bits together.
- It is simpler to analyse a file's permissions, because fewer operations are involved.
¹ They can change when a setuid or setgid process is executed. This isn't related to the issue at hand.
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
You seem to understand the concept of permissions, but I think you're getting caught up on user/group/other and what those mean in various contexts.
Briefly,
A file on disk has two owners. The
user
owner and thegroup
owner. For any particular file,other
is any user account that does not match theuser
nor is a member of thegroup
. In other words,other
is any user that is not the user owner and is not a member of the group owner.Further, each process runs under a specific User ID (or UID), and is a member of one or more Group ID's (GID). Use the command
ps -ef
(on Linux and Solaris, orps -ej
on OS X or *BSD) to see the user executing each process. You'll see that apache and ws_ftp are also being executed by users.When a process tries to access a file on disk the following happen:
UID
of the process matches theuser
owner of the file thenuser
permissions are enforced.GID
s of the process match thegroup
owner of the file thengroup
permissions are enforced.other
permissions are enforced.To answer your questions specifically:
Technically yes, because there is always an owner, but it depends on your definition of "I".
If you are logging in as a real POSIX user on the system then files you create/access will be as the user you logged in as. If you logged anonymously then the files you create/access will be that of the UID of WS FTP. This will likely be either
ftp
ornobody
.The web browser is not anything because it's not being executed on the server. But the browser accesses a web server. The web server is running as some specific user (just like WS_FTP is). That user is likely
www-data
,apache
ornobody
.PHP scripts are executed by the scripting engine module of the web server. They will be executed as the same user running the web server.
Yes. Read means that the user can read the contents of the file. Execute means that the contents can be run as a full fledged process.
Since PHP scripts execute inside the scripting engine of the web server (i.e., they are part of the memory space and execution thread of the server) they do not need to be set executable.
inetuser
is a user account on the system, just like your account. It may also be a group. Hopefully you can answer this question yourself after reading through this.Generally, you want data files to be owned by user accounts that are used by actual humans (i.e., you). In other words, your web content should not be owned by the apache user.