* Rici Lake <[EMAIL PROTECTED]> wrote: > Basically, ap_directory_walk will, under certain circumstances, attempt > to read an .htaccess file from a complete filepath; that is, given the > path /path/to/file, it will *also* try /path/to/file/.htaccess. This is > not because it has been lied to by the filesystem; it does this to > avoid excess calls to lstat() when it thinks it can get away with it. > > ap_parse_htaccess compensates for this by treating ENOTDIR as though it > were ENOENT. The filesystems I have kicking around all seem to return > ENOTDIR in this case, but apparently Reiser4 returns EACCES. I don't > think this is "wrong" -- others may disagree -- but returning a > security violation rather than revealing the (non)existence of a > resource is a common approach.
SUSv3/POSIX disagrees as well. So I think, Mr. Reiser should just fix, what's broken. It's not such an uncommon case to test an arbitrary file path, if it's possible to open it. Actually, it's *the best* way to handle file opening (trying to open and look what error it gave). EACCES is just the wrong error, because it has different semantics. > Given the semantics of the Reiser4 > filesystem, it is possibly even a reasonable choice. In any event, > trying to interpret the precise semantics of error returns from random > filesystems is a mug's game. POSIX exists. You might also want to look into open(2). > It is worth noting that in the particular circumstances which give rise > to this error, ap_directory_walk could tell if the path refers to a > directory or a file; it should be possible to avoid walking too far, > although there may well be edge cases I haven't thought of. -> Race condition. > Alternatively, of course, ap_parse_htaccess could simply regard *any* > error as equivalent to the non-existence of the .htaccess file. -> Broken behaviour and very dangerous. (Consider authentication stuff in the file) nd
