ShibAccessControl Relative Paths to user web content
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
When using ShibAccessControl in a .htaccess file in our environment we encourage web content maintainers to place the xml file in the same location as the content they are maintaining (with a blocked file naming standard of course)
Unfortunately this requires a full path to the location where the .htaccess file already is. This causes issues with development, testing and production environments potentially having different root file paths.
We would like to be able to reference the .xml relatively based on the location of the .htaccess
As discussed this could not be the default option as it would break exist config for other users
so just as a suggestion - maybe a new ShibAccessControlPath option - which defaults to the currently used /etc/shibboleth
can take a new base file path or be set to AUTO to go off the .htaccess location
Below are some details about how to maybe get the current location of the .htaccess file (or <Directory> path etc)
"A cmd_parms structure is the first argument passed to all directive handlers" "char* path" "If the handler is being called to process a directive located in an access control file, 'path' will contain the path to the directory containing the .htaccess file"
I tested with htaccess and pure Directory blocks successfully.
Some access control policies are definitely going to be sensitive or give an attacker useful information, but here's some rope, have fun.
Scott Cantor February 22, 2012 at 4:17 AM
The current command also does NOT support relative pathnames because the file is being opened directly inside the Apache module, so this isn't a breaking change either. I can add the feature to check for a relative path and prepend the command structure field. It will be an "at your own risk" feature.
Scott Cantor February 22, 2012 at 3:59 AM
Initial tests are promising, I suspect if you stick to htaccess with it, path will be valid, so within reason it's probably ok to allow for that.
Scott Cantor February 22, 2012 at 3:23 AM
Unfortunately the header files for both old and new Apache suggest that the path member doesn't mean anything in any recent version, other than as a NULL/non-NULL flag that signals whether it's a virtual or physical location. That was pretty much my impression when you asked about it.
The book you're referencing is extremely out of date, BTW, that's why it's misleading.
If I have a chance, I'll run a few tests to verify whether the path is perhaps valid for htaccess files even if the header says it's not.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
When using ShibAccessControl in a .htaccess file in our environment we encourage web content maintainers to place the xml file in the same location as the content they are maintaining (with a blocked file naming standard of course)
Unfortunately this requires a full path to the location where the .htaccess file already is. This causes issues with development, testing and production environments potentially having different root file paths.
We would like to be able to reference the .xml relatively based on the location of the .htaccess
As discussed this could not be the default option as it would break exist config for other users
so just as a suggestion - maybe a new ShibAccessControlPath option - which defaults to the currently used /etc/shibboleth
can take a new base file path or be set to AUTO to go off the .htaccess location
Below are some details about how to maybe get the current location of the .htaccess file (or <Directory> path etc)
"A cmd_parms structure is the first argument passed to all directive handlers"
"char* path"
"If the handler is being called to process a directive located in an access control file, 'path' will contain the path to the directory containing the .htaccess file"
From pages 581-582 of
http://books.google.com.au/books?id=5jAuQBe2EsMC&pg=PA448&lpg=PA448&dq=writing+apache+module+current+directory&source=bl&ots=6ZFjq9Np0j&sig=COI3gcZbCJi6jkBONnvesdyCCyM&hl=en&sa=X&ei=iCNDT5qpFtCViAef17jvBA&ved=0CEYQ6AEwBA#v=onepage&q=htaccess&f=false