[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
>>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:
Anything else? I'm pretty sure I missed some files.


More information about the pmwiki-users mailing list