Re: Bug 31126: Reiser4
* 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
Re: Bug 31126: Reiser4
I want to make it clear here that I have never used Reiser4, so on a personal level the issue is somewhat academic. On 9-Sep-04, at 1:11 AM, André Malo wrote: 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. So, Apache is only going to work on POSIX systems, you're saying? Even under POSIX, there are cases where this particular piece of error analysis could fail. For example, the redundant open on pathname/.htaccess could return ENAMETOOLONG even though pathname was within limits and names a regular file. (Admittedly, that is a pathological case, but...) EACCES is just the wrong error, because it has different semantics. I tend to agree, but it's not totally clear. Reiser4's files can also function as directories, so ENOTDIR is incorrect. ENOENT seems like a reasonable choice, but POSIX also mandates the return of EACCES instead of ENOENT if search permissions are not present. I don't know enough about the Reiser filesystem to know how one specifies search permissions on a file which can also be a directory. 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. What about just changing line 930 of server/request.c from if (r-finfo.filetype to if (r-finfo.filetype *r-path_info All that will do is not optimise on the last segment; I don't see how not performing the optimization could create a race condition that didn't already exist.
Re: Bug 31126: Reiser4
At 11:12 AM 9/9/2004, Rici Lake wrote: EACCES is just the wrong error, because it has different semantics. I tend to agree, but it's not totally clear. Reiser4's files can also function as directories, so ENOTDIR is incorrect. ENOENT seems like a reasonable choice, but POSIX also mandates the return of EACCES instead of ENOENT if search permissions are not present. I don't know enough about the Reiser filesystem to know how one specifies search permissions on a file which can also be a directory. 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. What about just changing line 930 of server/request.c from if (r-finfo.filetype to if (r-finfo.filetype *r-path_info All that will do is not optimise on the last segment; I don't see how not performing the optimization could create a race condition that didn't already exist. You miss a case with this patch... Consider a request for /content/foo/index.php/extra-path-info The path doesn't end where you think it does, and directory walk would usually handle this case. Perhaps a patch to perform an extra sanity check on EACCES results is a better fix, at least introduced by a compile-time flag? Bill
Re: Bug 31126: Reiser4
On 9-Sep-04, at 12:48 PM, William A. Rowe, Jr. wrote: You miss a case with this patch... Consider a request for /content/foo/index.php/extra-path-info The path doesn't end where you think it does, and directory walk would usually handle this case. Perhaps a patch to perform an extra sanity check on EACCES results is a better fix, at least introduced by a compile-time flag? I'm sure you know the code better than I do. I thought that r-info.filetype would be 0 in this case, since extra-path-info doesn't exist; in which case the optimisation is already being skipped. But I might be completely out to lunch. R,
Re: Bug 31126: Reiser4
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.
