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:
- 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. - 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.
- Pick a victim user, let's call him
barney
. Chown all of these files tobarney
, 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.
|
|