Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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
share|improve this question
add comment

4 Answers 4

up vote 23 down vote accepted

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...
share|improve this answer
add comment

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.

share|improve this answer
2  
Right. I modified the question to be clear the I was referring to files user owns and not any file. –  Alexandru Jul 16 '10 at 19:56
1  
@Alexandru: think of a malicious user changing myTrojan.sh to be owned by root and to have a SUID flag. –  Benjamin Bannier Jul 16 '10 at 20:00
    
@honk: makes sense now. –  Alexandru Jul 16 '10 at 20:08
add comment

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.

share|improve this answer
    
Quotas are always based on file ownership, not location. Otherwise someone could keep everything in /tmp. –  grawity Mar 29 '11 at 4:50
add comment

Because then the user can evade filesystem quotas. If I've got a quota of 100MB and you've got a quota of 100MB, I can upload 100MB, chmod a+r, chown you, then upload another 100MB.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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