105

Why is the chown command root-only? Why can't non-root users use chown to give away files they own?

m-ric
  • 125
phleg
  • 1,051
  • cant understand your question chown command can be used by non root user also – harish.venkat Dec 21 '11 at 20:56
  • Maybe i put it wrong. Well the exact question of my proffesor was: "Why the move of rights from a normal user isn't allowed in UNIX systems?"... – phleg Dec 21 '11 at 20:59
  • 23
    I think the real question is: why can't non-root users use chown to give away files they own. (I've seen systems where, depending on the filesystem configuration, you can.) – Keith Thompson Dec 21 '11 at 21:49
  • related: https://askubuntu.com/questions/95985/is-it-possible-to-change-ownership-of-a-file-without-root-access/1063606 – Ciro Santilli OurBigBook.com May 29 '19 at 09:26

3 Answers3

121

Most unix systems prevent users from “giving away” files, that is, users may only run chown if they have the target user and group privileges. Since using chown requires owning the file or being root (users can never appropriate other users' files), only root can run chown to change a file's owner to another user.

The reason for this restriction is that giving away a file to another user can allow bad things to happen in uncommon, but still important situations. For example:

  • If a system has disk quotas enabled, Alice could create a world-writable file under a directory accessible only by her (so no one else could access that world-writable file), and then run chown to make that file owned by another user Bill. The file would then count under Bill's disk quota even though only Alice can use the file.
  • If Alice gives away a file to Bill, there is no trace that Bill didn't create that file. This can be a problem if the file contains illegal or otherwise compromising data.
  • Some programs require that their input file belongs to a particular user in order to authenticate a request (for example, the file contains some instructions that the program will perform on behalf of that user). This is usually not a secure design, because even if Bill created a file containing syntactically correct instructions, he might not have intended to execute them at this particular time. Nonetheless, allowing Alice to create a file with arbitrary content and have it taken as input from Bill can only make things worse.
terdon
  • 242,166
Gilles 'SO- stop being evil'
  • 829,060
  • 4
    At a previous job, I built a software system that depended on the inability to give away files. It used file ownership to verify that a request had been submitted by a particular user. It checked, during installation, whether giving away files was permitted, and if so it refused to proceed. – Keith Thompson Dec 22 '11 at 03:09
  • 3
    Another more critical issue is that a user could copy /bin/bash, setuid it, and then chown it to whoever they want. Now they have shell access as that person. – phemmer Mar 29 '13 at 22:30
  • 22
    @Patrick chown always clears the setuid and setgid bits. – Gilles 'SO- stop being evil' Mar 29 '13 at 23:06
  • 1
    @Gilles and for good reason... if you could copy a shell binary somewhere you can access it, set the setuid/gid bits on it, and chown it to root (or any order thereof that gets you 6755/0:0 perms/ownership) you can obtain root on that system. Oh missed Patrick's comment, exactly. – hanetzer Dec 16 '14 at 08:30
  • Ok, but if I own the dir (drwxr-xr-x ring0 ring0 .) in which root has a regular file (-rw-r--r-- root root file),why can't I do chown ring0 file since it is anyway allowed to do, as ring0, cp file x ; rm file ; mv x file (and some optional touch sometime file ...) ? – Déjà vu Dec 05 '15 at 07:37
  • @ringø You didn't check all the required preconditions. For example, it shouldn't be allowed if the file has a hard link in another directory where you aren't allowed to delete it. It also shouldn't be allowed if the file is currently open, since the permissions on the file guarantee that root wrote its content. Even if you manage to find a set of conditions that ensure that it doesn't violate any security guarantee, that would be a hard-to-implement special case, and pointless since there's an easy workaround. – Gilles 'SO- stop being evil' Dec 05 '15 at 11:13
  • Digressing a little, it's interesting to note that while one can't chown a file one owns without sudo, one can chgrp a file one owns without sudo, provided the new group has one as a member. – flow2k Feb 24 '19 at 02:10
  • You can chown to yourself and another group you belong to, just like you can chgrp. – AturSams Feb 09 '23 at 07:13
19

On Linux, you need the CAP_CHOWN capability to chown. root is granted such. Refer to: http://vouters.dyndns.org/tima/Linux-OpenVMS-C-Implementing_chown.html for explanations. If you intend to give the CAP_CHOWN capability, build your code with libcap-ng or libcap as demonstrated by: http://vouters.dyndns.org/tima/Linux-PAM-C-Pluggable_Authentication_Modules_programming_example.html where you have to simple replace CAP_AUDIT_WRITE with CAP_CHOWN.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
user1910461
  • 191
  • 1
    +1 for you don't have to be root. Because you don't have to be root any more. – ctrl-alt-delor Feb 19 '15 at 23:38
  • 2
    Sometimes, you don't even need CAP_CHOWN: https://unix.stackexchange.com/questions/399975/how-come-i-as-a-normal-user-am-able-to-change-ownership-of-a-file From my read of the kernel source, each filesystem implementation is tasked with checking permissions for chown. And it appears that with NFS, the permissions are checked on the server side. And if the server is... strange... then it's possible. – Mike S Oct 25 '17 at 14:19
  • @MikeS: It makes perfect sense; each filesystem has its own idea how users are identified. Windows user identities for instance combine a machine-ID and a relative user-ID. And on network systems like NFS, your local UID is often equally meaningless. Anyone can be root locally. CAP_CHOWN is necessary but not sufficient. – MSalters Mar 10 '20 at 13:39
  • Umm; don't give CAP_CHOWN to normal users. If you want users to give their files away you need a lesser tool. CAP_CHOWN is a bit too much power. – Joshua Oct 27 '22 at 19:46
2

You can launch the command but it will not work if you are not root. It is easy : imagine a user which can change a software to root user. It can add the setuid bit and, voilà, the guy is root ! So, the use can add the bit with chmod, but no chance to change the owner of files.

Dom
  • 948
  • 13
    You can't add the setuid bit on a file you don't own, and implementations that allow giving away files clear the setuid bit. – Gilles 'SO- stop being evil' Dec 22 '11 at 00:55
  • 1
    I think the point of Dom's answer is this: Imagine if you could. Then there would be trouble. Your point, that you can't, is correct. But the OP is asking "why?" Clearing the setuid bit is another security feature that again begs the question "why?" Which I would then refer to Dom's answer: IF a user could chown, and IF a user could setuid, then that combo would be disastrous. I think he makes a fine point, even if he's missing a little bit. – Mike S Oct 23 '17 at 17:37