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

April 23, 2020

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.


Comments on this page:

By Joshua M. Clulow at 2020-04-23 04:41:49:

For what it's worth, I believe rstchown defaults to 1 on illumos, so we also have the BSD behaviour in general.

By Opk at 2020-04-23 05:42:47:

Back when I was an undergraduate, I think I was chowning my files to root or nobody rather than picking an actual victim. And we made good use of hiding files below /var/preserve which was where vi stored backup files – until one idiot filled up the physical disk that was on.

By Greg A. Woods at 2020-04-30 14:14:07:

My recollection is that disk quotas were mostly always seen as an issue and requirement restricted to the academic world. In the commercial world they never really served as much of a purpose. Even when I switched to using newer BSDs I never really found a use for them, not even on massively shared web servers with many naive users (where network usage quotas would have been much more valuable). Quotas also lose favour when disk space grows exponentially and drops in price like a stone (of course the management headache of "too many files!" never goes away).

As for why commercial "UNIX" was changed to allow users to give away files, well that was seen as the more secure way to transfer data between users who might not belong to (and be able to belong to) the same group (i.e. more secure than making the files world readable, or worse, world read+write). Remember commercial unix also only allowed a user to belong to just one group at a time, thus newgrp.

Written on 23 April 2020.
« More on chown in combination with symlinks
Accepting TLS certificate hostnames based on IP address checks is not safe »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Apr 23 00:20:26 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.