Messages in this thread |  | | From | Systemkennung Linux <> | Subject | Re: unlink system call on directories - Bug + fix | Date | 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
|  |