I believe (not sure) that the owner of a file/directory and the root user are the only users that are allowed to change the permissions of a file/directory. Am I correct or are there other users that are also allowed to change the permissions?
Add a comment
|
3 Answers
Only the owner and root (super user) are allowed to the change the permission of a file or directory. This means that the owner and the super user can set the read (r), write (w) and execute (x) permissions. But changing the user ownership of files and directories with the command chown is only allowed to root. Changing the group ownership with chgrp is allowed to root and the owner of the file, if the user is a member of the new group.
-
22The owner of a file may change the group ownership of that file if the user is member of the new group.– Kusalananda ♦Apr 11, 2017 at 8:39
For the purpose of normal operation, only root and the owner can chmod. In addition, root can chown and chgrp, and furthermore the owner can chgrp as long as the owner is a member of the target group.
For security purposes, there is another case though: any user with write permission to the directory containing the file can replace the file with a copy, and thus become the owner, gaining the ability to modify the permissions and contents.
Like so:
14:14 mybox:~ mkdir mydir
14:14 mybox:~ cd mydir/
14:14 mybox:mydir echo foo | sudo tee yourfile
foo
14:14 mybox:mydir ls -ld . yourfile
drwxr-xr-x 3 me staff 102 Apr 11 14:14 .
-rw-r--r-- 1 root staff 4 Apr 11 14:14 yourfile
We created a directory, and wrote a file as root. Since root owns the file, we cannot write to it, nor can we chmod:
14:15 mybox:mydir echo bar > yourfile
-bash: yourfile: Permission denied
14:15 mybox:mydir chmod a+x yourfile
chmod: Unable to change file mode on yourfile: Operation not permitted
However, we do have write permission to the directory, so we can replace the file to get ownership:
14:15 mybox:mydir mv yourfile yourfile2
14:15 mybox:mydir cp yourfile2 yourfile
14:15 mybox:mydir ls -ld . yourfile
drwxr-xr-x 4 me staff 136 Apr 11 14:15 .
-rw-r--r-- 1 me staff 4 Apr 11 14:15 yourfile
And now that we are the owner, we can of course do what we want with that file:
14:15 mybox:mydir echo bar > yourfile
14:15 mybox:mydir chmod a+x yourfile
14:16 mybox:mydir cat yourfile
bar
Similarly, any user with write permission to any directory in the full path leading to the file can replace the directory structure from that point on, thus gaining ownership of the file with the given name. The ownership or permissions of the actual original file (which we renamed to "yourfile2") isn't changed, of course.
14:17 mybox:mydir ls -l yourfile2
-rw-r--r-- 1 root staff 4 Apr 11 14:14 yourfile2
-
Do you know if any Linux distribution supports additional security features like Windows? If I am in Windows, I can set a file’s delete permission to denied to prevent deletion even when the directory is permissive.– Kevin LiApr 11, 2017 at 12:09
-
Many (most?) current Linux flavors support file level access control lists, (
getfacl / setfacl) which give more flexibility than the "classical" style file permissions. File deletion in *nix works by removing the link to the file from the directory, so file removal is always controlled by the directory permissions; the file permissions themselves play no role there.– BassApr 11, 2017 at 12:24 -
Very true to the Unix philosophy of “everything is a file.” So you are saying that such a thing cannot be done in Linux?– Kevin LiApr 11, 2017 at 12:43
-
4@KevinLi This answer isn't really complete. You can set the sticky bit on a directory to limit the ability of non-owners to delete or rename files. See this question and its answers: unix.stackexchange.com/questions/79395/… There's no need to use ACLs or other schemes. Apr 11, 2017 at 15:18
-
@KevinLi *nix filesystems are very different from Windows' ones. The files exist separately from the directory hierarchy, and they can have several "hard links" pointing to them in the directories. Deleting a file actually means removing the hard link, which is done on the directory. The file keeps track of how many hard links are pointing to it, and the actual file will stay on the disk as long as there's at least one hard link pointing to it. Thus, deletion is controlled by the directory permissions, which do have a special option to only allow deletes by file owner&root, as Andrew says.– BassApr 12, 2017 at 7:52
The chmod command fairly directly invokes the system call of the same name; the man page for the chmod(2) system call (on Linux 4.10) says:
The effective UID of the calling process must match the owner of the file, or the process must be privileged (Linux: it must have the
CAP_FOWNERcapability).If the calling process is not privileged (Linux: does not have the
CAP_FSETIDcapability), and the group of the file does not match the effective group ID of the process or one of its supplementary group IDs, theS_ISGIDbit will be turned off, but this will not cause an error to be returned.
So yes, a process running as root can change any file's permissions if it has not dropped the CAP_FOWNER capability.
Also of interest is chown; the man page for chown(2) says:
Only a privileged process (Linux: one with the
CAP_CHOWNcapability) may change the owner of a file. The owner of a file may change the group of the file to any group of which that owner is a member. A privileged process (Linux: withCAP_CHOWN) may change the group arbitrarily.
answered Apr 11, 2017 at 14:50
