Messages in this thread | | | Date | Wed, 16 Jun 1999 13:41:20 -0400 (EDT) | From | Alexander Viro <> | Subject | [RFC] Bug in mkdir(2) |
| |
Sigh... Looks like we got Yet Another Symlink Hole(tm). Not too serious one, since probably no suid-root stuff is perverted enough to trigger it, but anyway. Scenario: $ ln -sf b a $ ls -ld a b ls: b: No such file or directory lrwxrwxrwx 1 al al 1 Jun 16 12:56 a -> b $ mkdir a mkdir: cannot make directory `a': File exists $ mkdir a/ $ ls -ld a b lrwxrwxrwx 1 al al 1 Jun 16 12:56 a -> b drwxrwxr-x 2 al al 1024 Jun 16 12:58 b
In other words, if foo is a dangling symlink mkdir("foo/") will merrily follow it. Which it shouldn't.
There are 3 reasonable variants of fix and they give different error values - -ENOENT (if we are treating it as a dangling link in the middle of lookup), -EEXIST (if we refuse to follow link here and ignore the trailing /) or -ENOTDIR (ditto, but noticed that it's not a directory). Take your pick ;-) Solaris prefers the second variant and IMO it's the right thing.
BTW, rmdir("foo/") also shouldn't follow links. rmdir(1) works around that (it trims the trailing slashes), but IMHO rmdir(2) shold return -ENOTDIR here. Actually it happily follows the link.
Patching it either way is fairly trivial and I'll submit the patches as soon as you will choose the variant. I think that the right thing to do here is to -EEXIST for mkdir() and -ENOTDIR for rmdir(). Up to you, indeed. Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |