14

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?

19

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 ownership (user/group) of files and directories with the commands chown/chgrp is only allowed to root.

  • 18
    The owner of a file may change the group ownership of that file if the user is member of the new group. – Kusalananda Apr 11 '17 at 8:39
6

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 Li Apr 11 '17 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. – Bass Apr 11 '17 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 Li Apr 11 '17 at 12:43
  • 3
    @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. – Andrew Henle Apr 11 '17 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. – Bass Apr 12 '17 at 7:52
1

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_FOWNER capability).

If the calling process is not privileged (Linux: does not have the CAP_FSETID capability), and the group of the file does not match the effective group ID of the process or one of its supplementary group IDs, the S_ISGID bit 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_CHOWN capability) 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: with CAP_CHOWN) may change the group arbitrarily.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.