httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli" <>
Subject [users@httpd] Getting more control over security/permission settings
Date Wed, 01 Sep 2004 17:54:49 GMT
I've been trying to figure out a workaround to a huge problem I have with my
webservers.  The problem is mainly caused by the requirement for the
webservers to have the RTR FrontPage extensions available on them as well.

By having the FrontPage extensions on the server, I am required to set
"AllowOverride All" to the root folder of all my websites, so that the
FrontPage extensions stuff can work - it creates .htaccess files with
"Options" settings and such to try and control security per directory.  I
don't believe there is any way around this problem with the FrontPage
extensions, as my problems would be instantly solved if I could instead just
use FilesMatch to create one global regex type set of permissions for the
special FrontPage folders.  This isn't the case however :P

So, because I have to (grr) grant "AllowOverride All" to every user, I've
now lost hold of my control over their settings.  Most notably are the
abilities to enable/disable CGI and SSI execution.  I want to be able to
have final say (by changing settings in their VirtualHost directive) over
the enabling/disabling of such settings.  However, because users can now use
Options, as much as I set -ExecCGI (as an example) in their VirtualHost
directive, they can just turn around and make an .htaccess file and
re-enable it.

So, my following choices that I've thought of are as follows:

* Have the ability to redefine the sequence of directory/file directive
properties.  Such that I can specify that DirectoryMatch and FilesMatch
would be loaded *before* any .htaccess settings.  This would allow me to
enable AllowOverride All *only* on the special (_vti_*) FrontPage folders
while retaining control over all other files/folders

* Have the ability to define finer grained settings for AllowOverride, such
that I could just allow "Options None" (as an example) or what have you.
This would allow you to permit/deny certain options to the various
directives you can control with AllowOverride.  With this, I could just
allow the use of "Options None" to be used, so that users could only turn
off options (this is the Options line in FrontPage extensions), and nothing

* Have the ability to redefine the load order of settings in general.  This
would allow me to move the processing of .htaccess files after everything
*except* the VirtualHost section, so that my (administrators) settings would
override those in any .htaccess files.  This probably would be best tied in
with my 1st suggestion so that it makes more sense - not only would I want
to move the load order of the settings, but how and when the settings are
applied/evaluated as well.

Unfortunately, all of these 3 possiblities which would solve my issues are
not possible in Apache.

The only other solution I could think of that wouldn't involve Apache, is to
try and get the RTR people who make the FrontPage extensions to have the
creation of the .htaccess files for controlling FrontPage as an *option*
rather than a requirement.  Then I wouldn't need to use "AllowOverride All",
rather I could just define the permissions in some DirectoryMatch directives
globally.  ... But then, that's just a fix for FrontPage extensions...

However, since not many people seem to be able to persuay RTR (eg, trying to
get FrontPage extensions to authenticate over LDAP), I was hoping for maybe
some action in Apache.  Are the suggestions (all three of them would be
best) within reason for feature requests?  Or is/are there modules available
to take care of these sorts of issues rather than change Apache itself?
I've searched high and low for something to help and I've come up blank.
I'm quite interested in any comments/solutions.


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message