|Summary:||mod_dav PROPFIND ignores access restrictions on items in a collection|
|Product:||Apache httpd-2||Reporter:||Anthony Atkins <anthony.atkins>|
|Component:||mod_dav||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Attachments:||Hack to exclude ms office 2010 generated temporary files|
Description Anthony Atkins 2006-08-08 21:32:07 UTC
I have the following block in my httpd.conf, outside of any Virtual Host directive: <FilesMatch "^\.(perms.xml|home.xml|htaccess|davaccess|htaccess.ssl|localUsers|localGroups|ftpaccess)$"> Order allow,deny Deny from all Satisfy All </FilesMatch> This block is intended to hide files that control access for apache and another app that reads the filesystem. When accessing the space using a web browser, all files matching the pattern above are hidden as expected. When using a DAV client such as WebDrive, the files are returned in the directory listing. This causes problems when attempting to copy a folder containing hidden files to a new location, as the DAV client is aware of the hidden file and tries to copy it. It seems like one or more dav permissions is not correctly limited in a general FilesMatch block, when in fact all permissions for both DAV and non-DAV access should be removed by the above block.
Comment 1 Ruediger Pluem 2006-08-09 20:28:12 UTC
(In reply to comment #0) > I have the following block in my httpd.conf, outside of any Virtual Host directive: > > <FilesMatch > "^\.(perms.xml|home.xml|htaccess|davaccess|htaccess.ssl|localUsers|localGroups|ftpaccess)$"> > Order allow,deny > Deny from all > Satisfy All > </FilesMatch> > > This block is intended to hide files that control access for apache and another > app that reads the filesystem. When accessing the space using a web browser, From my point of view this is not what filesmatch is designed for. You can prevent access to these files, but not prevent showing them. Think of Unix filesystem permissions: You may have files in a directory on which you have no permissions. As long as you have read permissions on the directory you can see them. > all files matching the pattern above are hidden as expected. What do you mean by hidden? Do you have configured mod_autoindex and they don't show up in the mod_autoindex generated listings? > > When using a DAV client such as WebDrive, the files are returned in the > directory listing. This causes problems when attempting to copy a folder As stated above I would see this as works as designed.
Comment 2 Anthony Atkins 2006-08-09 20:39:59 UTC
I disagree that FilesMatch is not intended to hide files, mod_autoindex does not display files that match the above patter. Moreover, you get a "403 Forbidden" when trying to read a file that matches the FilesMatch pattern from any web browser. Again, everything *but* DAV honors the FilesMatch directive as specified. Anyway, if you don't think FilesMatch should be used in this way, how would you suggest preventing a DAV client from seeing access control files?
Comment 3 Ruediger Pluem 2006-08-09 21:15:48 UTC
(In reply to comment #2) > I disagree that FilesMatch is not intended to hide files, mod_autoindex does not In order to prevent files from showing up in a mod_autoindex listing and thus hiding them, you should use IndexIgnore. I guess it is just because mod_autoindex fails to detect the mime type of the file that it does not display it. But this not really intentional. > display files that match the above patter. Moreover, you get a "403 Forbidden" > when trying to read a file that matches the FilesMatch pattern from any web In this case you try to access the file itself. That is what filesmatch prevents and should prevent. This is also prevented in the dav case. You can *see* the files in Webdrive but you *cannot* access them. > browser. Again, everything *but* DAV honors the FilesMatch directive as specified. What do you mean by everything? I see only mod_autoindex and the behaviour there is not intentional. > > Anyway, if you don't think FilesMatch should be used in this way, how would you > suggest preventing a DAV client from seeing access control files? This is not possible. Again think of the Unix filesystem permissions here. If you want to prevent someone from *seeing* files in a directory you have to revoke read permissions on this directory. The same is true for mod_dav. Seeing a file is not a property or permission of the file, but of the directory or better the collection in the dav case. But of course you can prevent people from accessing the access control files via filesmatch.
Comment 4 Anthony Atkins 2006-08-09 21:43:40 UTC
IndexIgnore doesn't affect the DAV functionality. I explicitly added all of the access control files to an IndexIgnore block and they still show up. Try it and see.
Comment 5 Anthony Atkins 2006-08-09 21:55:09 UTC
>>Again, everything *but* DAV honors the FilesMatch directive as specified. >> >What do you mean by everything? I see only mod_autoindex and the behaviour there is not intentional. > GET access to the file itself is limited by the FilesMatch directive, as is the display of the file in the index created by mod_auto_index. That's what I meant by "everything". If you're saying you can't limit GET access to a file, you're mistaken. Apache can definitely be configured not to display directories or files for which it itself has read access.
Comment 6 Anthony Atkins 2006-08-09 22:01:53 UTC
Okay, didn't mean to sound so harsh. I reread your note, I understand your point about the containing directory. But to extend your analogy, if I have the permissions necessary to read a directory, but I'm not allowed to read a file by an ACL, then I won't see the file in the directory listing, period. You need both permissions to be able to see a file in a directory listing, which is my point. DAV is apparently honoring the directory permissions and ignoring the file permissions.
Comment 7 Ruediger Pluem 2006-08-10 08:03:19 UTC
(In reply to comment #5) > > If you're saying you can't limit GET access to a file, you're mistaken. Apache I did not say this I said the opposite. > can definitely be configured not to display directories or files for which it > itself has read access. But this is only true if the IndexOption ShowForbidden is not set. So I must correct myself a little bit regarding the 'non intentional' statement. Depending on the configuration setting of mod_autoindex this behaviour is intentional.
Comment 8 Ruediger Pluem 2006-08-10 08:08:34 UTC
(In reply to comment #6) > Okay, didn't mean to sound so harsh. I reread your note, I understand your > point about the containing directory. But to extend your analogy, if I have the > permissions necessary to read a directory, but I'm not allowed to read a file by > an ACL, then I won't see the file in the directory listing, period. You need This is just plain wrong on a standard Unix file system. If you have the permission to read the directory you see the file in the directory listing. I admit that I don't know if this behaviour changes if you are using POSIX ACLS. BTW: The same seems to be true with NTFS on Windows.
Comment 9 Anthony Atkins 2006-08-10 13:00:15 UTC
The default behavior of mod_autoindex is not to show files that are restricted by a FilesMatch block. Also, I specifically used the example of ACLs because those are a better match for what FilesMatch does than regular UNIX perms. Anyway, I'm going to try a demonstration, I suspect that it's just one of the methods that's not working as expected. Have you tried to replicate this?
Comment 10 Anthony Atkins 2006-08-10 13:57:20 UTC
Okay, I just did some testing. The files are not revealed when using the GET method, but are revealed when using the PROPFIND method with a depth of 1. So it seems like all this talk about mod_autoindex is beside the point. It's the PROPFIND handling in mod_dav that exhibits the unexpected behavior.
Comment 11 Joshua Slive 2006-08-10 14:29:05 UTC
I'm no DAV expert, but I do believe there is a bug here. If you look at the PROPFIND multistatus response for such a directory, I believe it should be showing a different status and omitting the get* elements for access-restricted files. Instead, it is showing them just like any other file.
Comment 12 Joe Orton 2006-08-10 14:39:06 UTC
[collision with joshua] I completely agree with Ruediger that the correct behaviour should be to reveal the existence/non-existence of a resource by name in mod_dav. mod_dav does not however apply any access control checks during a PROPFIND walk, which is certainly a bug: you can do a Depth: infinity walk straight through protected areas, and discover properties of protected resources in a Depth: 1 even if infinity is disabled. Fixing this was somewhat more complicated that just adding a subreq call in the walker because of the error handling IIRC from working on this for mod_dav 1.0. Returning simply a name in a 200 propstat for protected resources is probably correct; not sure how DAV clients will react to such resources though.
Comment 13 Anthony Atkins 2006-08-10 15:04:28 UTC
I have a pretty good idea how DAV clients react, having testing mod_dav with WebDrive, Web Folders, and the DAV support built into OS X. In our case, all the files we hide (.davaccess), etc. start with a leading dot. If the client program is configured to hide "dot files", then the name/icon of the file will not be displayed to the end user. If the client program is configured to display "dot files", the name/icon will be displayed. All three clients base their directory listings on the results of the PROPFIND. If a user attempts to copy a directory containing restricted files, the client will attempt to request the restricted files and fail with an error. This is precisely why I reported this problem.
Comment 14 Joshua Slive 2006-08-10 17:19:15 UTC
Anthony, the question isn't how clients now react, it is how would they react if the PROPFIND response was correct (including the restricted files, but with the correct status and without the extra details).
Comment 15 Anthony Atkins 2006-08-10 17:39:05 UTC
Ah, got it. I could probably arrange for a perl script to pretend to be Apache and return an edited replay of a normal propfind. I'll let you know what I figure out.