Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> In reviewing parts of remove.c I noted (again) the race condition on
>> systems with an unlink that may remove directories, so added this comment:
>>
>> +/* If anyone knows of another system for which unlink can never
>> + remove a directory, please report it to [EMAIL PROTECTED]
>> + The code below is slightly more efficient if it *knows* that
>> + unlink(2) cannot possibly unlink a directory. */
>>
>> On non-glibc systems that race condition means that there's a window
>> via which a privileged rm user might be tricked into unlinking a
>> nonempty directory.
>
> Why do you think that has anything to do with glibc?
Hmm.. You're right. `man 2 unlink' suggests that it is
Linux (since 2.1.132) specific, not glibc-specific.
Long ago, I must have read `info libc's "Deleting Files" section:
`EPERM'
On some systems `unlink' cannot be used to delete the name of
a directory, or at least can only be used this way by a
privileged user. To avoid such problems, use `rmdir' to
delete directories. (In the GNU system `unlink' can never
delete the name of a directory.)
and mistook `GNU system' for glibc-based system.
So the current test of __GLIBC__ may be wrong if the
underlying kernel is not Linux.
I'll change it to __linux__.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
