Bug 40217 - mod_dav PROPFIND ignores access restrictions on items in a collection
Summary: mod_dav PROPFIND ignores access restrictions on items in a collection
Status: REOPENED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.2.2
Hardware: PC Linux
: P2 normal with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-08 21:32 UTC by Anthony Atkins
Modified: 2014-08-15 06:12 UTC (History)
1 user (show)



Attachments
Hack to exclude ms office 2010 generated temporary files (1.01 KB, patch)
2014-08-15 06:12 UTC, ralf.habacker
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.
Comment 16 ralf.habacker 2014-08-15 06:12:12 UTC
Created attachment 31920 [details]
Hack to exclude ms office 2010 generated temporary files

This patch excludes temporary files generated by ms office 2010 from the webdav directory listing.