Why unprivileged user can't change file ownership?

From chown(2):

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.

What's the reason for this restriction? Why an unprivileged user can't change file ownership of a file it owns (ie. no /etc/shadow)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted

Solution 1:

By allowing users to "give away" files you run afoul of various features of the OS. Such as:

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...

Solution 2:

It's just a personal choice of the linux designers not to allow it -- all the pseudo-security reasons, given, are specious, as there are unix systems that allow this.

I think this functionality came down to whether or not your unix's behavior followed 'System-V' (AT&T) or Berkeley's unix (BSD)...

As for other security issues mentioned:

• Impersonating another user (or even root) via setuid.

  Non-issue: Changing 'owner' clears any 'setXid' bits (U/G)

• Having insufficient privileges to undo a mistaken chown

  Not really a 'security risk', BUT, it might be on systems that allow changing user, you can change it back if it is in a directory you own, other wise: 'be careful'!

• Making it appear that someone else had created a given file.

  It would still be in a directory that is writable by you. I.e. you couldn't move it into their homedir, unless the have it open for write to your group or all (or you specifically if ACL's are available).

• Setting up cron jobs to run on other user's accounts.

  Again, wouldn't work -- since the crondirs are owned by user and not set to even be readable by other users, let alone writable.

• if anyone could change the ownership, then anyone could change the permissions to gain access to any file on the system.

  Nope: only if the user 'owns' the directory containing that file. I.e. I can give a file named 'passwd' to root, but I couldn't move it into /etc/ unless I have write permission to /etc/.

• quotas

  A potentially valid point -- IF you use quotas, but it seems like it would be easy to detect if you sum-up disk space by home-dir; The only problem would be in dirs that are writable by multiple users. In which case, maybe going by the owner of that 'dir'. It MAY be the case on those systems that support 'giving away' files, that you can only do this in directories that you 'own', but it's been a LONG time since I've actually been on a system that allows this, so I don't remember the exact restrictions.

I seem to remember there being some 'trade-off' for allowing 'giving away files'... e.g. - on systems that allowed that, something else wasn't allowed that linux does allow, but can't remember what that was off hand...

I'd say the above 'answer' should be unmarked as the answer, as it's NOT the real answer. IT's more a design decision -- I just don't know what the tradeoff(s) were.

There may be security issues not raised above that would be valid concerns, but the ones above aren't valid.

IMO, it should be a system-settable 'value' in "/proc", but generally speaking, I think most people don't care that much.

If there was a strong need for it, 'chown' could be security-enhanced and modified to allow it and then setup w/setuid 'root' to enable it to implement such a policy.

Solution 3:

Well, if anyone could change the ownership, then anyone could change the permissions to gain access to any file on the system. This is bad not only from a malware standpoint (no sudo required), but from the standpoint of a sysadmin. If any of the users could change any of the files, then file permissions are useless.