Wandering Thoughts archives

The Unix divide over who gets to chown things, and (disk space) quotas

One of the famous big splits between the BSD Unix world and the System V world is whether ordinary users can use chown (the command and the system call) to give away their own files. In System V derived Unixes you were generally allowed to; in BSD derived Unixes you weren't. Until I looked it up now to make sure, I thought that BSD changed this behavior from V7 and that V7 had an unrestricted chown. However, this turns out to be wrong; in V7 Unix, chown(2) was restricted to root only. The manpage even says why:

[...] Only the super-user may execute this call, because if users were able to give files away, they could defeat the (nonexistent) file-space accounting procedures.

(V7 didn't have any direct support for disk quotas or file space accounting, although you could put together various things to at least monitor who was using how much space by sweeping over the filesystem.)

In 4.2 BSD, UCB CSRG added disk quotas (I believe as part of the new 4.2 BSD Fast File System), and so they kept the restriction on chown(2). Now that they had real disk quotas, the threat of undergraduates and other people defeating them with chown was quite real and had to be avoided.

(4BSD didn't have disk quotas but it did have a quot(8) command to analyze the filesystem and tell you per-user usage information, so this area was on CSRG's collective minds for a while. It operated by scanning the raw filesystem through the disk, per quot.c.)

On the System V side, the restriction on chown(2) appears to have been lifted in System III (32V Unix still has it). I don't know why it was removed, but System III has no disk quota system and the change is clearly deliberate, as the chown(2) manpage has been updated to document the new state of affairs. This was carried through to System V, where it became well known (and common, as System V spread).

All of this left POSIX with a little bit of a mess, which POSIX solved by allowing both behaviors in the POSIX chown() specification. In fact POSIX goes further than a system wide choice; things may differ on a path by path basis, with some paths permitting normal people to give away their files and some not.

(In fact the 'rationale' section of the POSIX chown() specification has a thorough recounting of the historical differences that led to the situation, and confirms that normal UIDs being allowed to give away ownership was a System III addition.)

Pretty much all common modern Unixes have come down on the BSD side of this divide. The *BSDs inherited the original V7 and 4.2 BSD restriction on chown(2), and Linux copied or adopted it. Illumos inherited from System V R4 through Solaris, and appears to have a chown(2) that by default follows the System V behavior of allowing anyone to give away files; however, its chown(2) manpage documents a system wide way to turn this off, among other options.

(It's my view that a restricted chown(2) is the right choice even if you ignore disk quota issues, but that's another entry.)

Sidebar: How to safely defeat disk quotas by chowning away your files

Because this may not be obvious, let's suppose that you are an undergraduate on a system that implements disk quotas (based on file ownership) but permits you to chown them to other people. Then you can get around your disk quota as follows:

1. Make a restricted directory somewhere. Perhaps you can call it $HOME/assignments; no one is going to fault you for making that only accessible by you.

2. Create your (big) files in this restricted directory or a sensible subdirectory of it, making them world readable (or perhaps only group readable to a group you're in), and executable if necessary. You can also make them writeable if you need to.

3. Pick a victim user, let's call him barney. Chown all of these files to barney, who suddenly gets charged for their space usage.

You retain access to these files although barney now owns them, because giving them away didn't change their file permissions in any important way. Barney doesn't have any access to them because they're hidden away inside an inaccessible directory; standard Unix gives normal users no way to find such files or to manipulate them once they're found. And if you need to make the evidence go away or just change things around, you can delete the files because you still own the directories they're in.