Re: unlink system call on directories - Bug + fix

Systemkennung Linux (linux@mailhost.uni-koblenz.de)
Mon, 18 Nov 1996 14:56:51 +0100 (MET)


> Correct, but not that uncommon, at least not on some older boxes.
>
> In several older BSD-based boxes I have seen you could do unlink's of
> directories *IF* you were root (owning the directory wasn't enough), with
> exactly that effect. You couldn't do it using rm (it checked first), but
> the system call supported it.

This goes back to the roots of UNIX - AT&T Edition 7 has the same problem.
The reason that unlinking a directory requires root priviledges on certain
operating systems is just to make shure that users use the setuid root
program rmdir to remove a directory. Using unlink as root makes it
possible to do interesting things like unlinking "<dirname>" but not
"<dirname>/." Now a directory exists which is only via it's ".." entry
linked with the rest of the directory structure. The inode usage counter
still isn't zero, so the kernel won't unlink it. Later fsck will
notice that directory with contents like:

(... V7 live session ... heating up the tubes ...)
# mkdir xxx
# cd xxx
# unlink .
# ls -la
total 1
drwxr-xr-x 10 root root 1024 Nov 18 15:54 ..
#

exists and will fix it. (unlink(8) is a V7 filesystem tool that directly
calls unlink(2).)

Everything coherent with the UNIX design guideline "do in userspace
what can be done in userspace" rmdir was implemented in userspace and
unknowing users of the syscalls got burned quite often.

Ok, enough UNIX history ...

Ralf