[pmwiki-users] How use lowercase in Group Names
Joachim Durchholz
jo at durchholz.org
Thu Sep 29 10:11:52 CDT 2005
Patrick R. Michaud schrieb:
> On Wed, Sep 28, 2005 at 10:06:12PM +0200, Joachim Durchholz wrote:
>
>>Waylan Limberg schrieb:
>>
>>>RewriteCond %{REQUEST_FILENAME} !-f
>>>RewriteRule ^(.*)$ phwiki.php?n=$1 [QSA,L]
>>>
>>>The key is the "!-f" part which essentially means: 'If the requested
>>>file name does not exist use this rewrite rule, otherwise proceed as
>>>normal'.
>>
>>Hmm... I see pros and cons for that.
>>
>>On the pro side, you can structure your namespace simply by creating the
>>appropriate files. Easy and convenient.
>>
>>On the con side:
>>
>>1. This gives access to all directories, even those that are supposed to
>>be restricted... think wiki.d/Site.SideBar, which then anybody could
>>download including passwords and all other attributes.
>
> Surely the existence of the "!-f" doesn't cause Apache to bypass any
> .htaccess files or other access controls that may be in place
> (such as the one that is already in wiki.d/.htaccess).
Probably not... but I'm not 100% sure. mod_rewrite (ab)uses the internal
framework of Apache in unanticipated ways, and I'm not 100% convinced
that Apache is still sure about the URL-to-location mapping after
mod_rewrite has done its thing.
mod_rewrite definitely introduces new concepts into that mapping
machinery (that's why it has RewriteBase).
I'd judge things in a somewhat more relaxed mood if everybody were using
Apache 2.0 - AFAIK 2.0 was designed with better support for things like
mod_rewrite in mind. OTOH the Apache team failed on at least one other
architectural improvement (suEXEC), so I'd check anyway :-)
> As I read the above rewrite rule, it says to rewrite
> the url only if the url *doesn't* correspond to a file in the
> filesystem. If the url does correspond to a file, then the rewrite
> rule doesn't fire, and execution continues on as if the rewrite rule
> wasn't present. In this sense it's no more or less secure than the
> other CleanURL approaches.
Security is affected only insofar as with any defaulting strategy: it's
a bit more difficult to find out which things get served from where.
Sorry for not making this clearer in my previous post.
One thing that I don't like about "if it exists as a file, serve it
without intervention from pmwiki.php" is that additional files will show up.
For a clean installation, this means that visitors will get to see
COPYING and README. This doesn't open up security holes, but these files
aren't /supposed/ to get served. Any other files that the administrator
happens to place there aren't supposed to get served, too - or maybe
they *are* supposed to get served, but then the administrator should say
so somewhere. And since "saying so" is an additional configuration
complexity, I'd still recommend sticking with not serving anything but a
hardcoded list of administrative files from the installation directory,
and tell people to put servable stuff into the pub/ hierarchy.
Off the top of my head, the hardcoded list would include:
pmwiki.php
favicon.ico
robots.txt
Anything else? I'm pretty sure I missed some files.
Regards,
Jo
More information about the pmwiki-users
mailing list