Re: Bug 31126: Reiser4

[Rici Lake]

I put the gory details on Bugzilla 
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31126); I honestly 
don't know what the best way to fix this problem is, though.

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. 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.

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. Otherwise, 
not optimising away the lstat() in last step of the directory walk may 
be the best solution.

Alternatively, of course, ap_parse_htaccess could simply regard *any* 
error as equivalent to the non-existence of the .htaccess file.