15

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
Improve this question

4 Answers 4

Reset to default
27

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...
Improve this answer
8

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.

Improve this answer
2
  • Quotas are always based on file ownership, not location. Otherwise someone could keep everything in /tmp.
    – u1686_grawity
    Mar 29, 2011 at 4:50
  • +1, you seem damn right :). On OpenSolaris systems (which is indeed a System V descendant) you can set this through a mount option (this setting can therefore be limited to a single mount point instead of being system-wide as per your system-settable value suggestion): rstchown (the default) to limit file owner changes to the root user, norstchown to allow unprivileged users to change the owner of their own files (they cannot change it back).
    – WhiteWinterWolf
    Jan 22, 2016 at 18:03
6

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.

Improve this answer
3
  • 2
    Right. I modified the question to be clear the I was referring to files user owns and not any file.
    – Alexandru
    Jul 16, 2010 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, 2010 at 20:00
  • @honk: makes sense now.
    – Alexandru
    Jul 16, 2010 at 20:08
5

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .