setting include_path on shared server

[Chuck Anderson]

My shared host used to have Php configured such that I could place a
php.ini file into any directory on my site and that was the php.ini file
that the Php cgi would use when it ran scripts.

Since upgrading to Php5.1 that is no longer possible (not allowed in
Php5.1 (?) ).

Anyway, ... this was a very handy way for me to set the include path so
that I could keep files with sensitive data (e.g., database usernames,
passwords) out of the site's public path.

My hosting service has actually rolled back to Php5.0 so that I could
continue doing as I had been ... with the caveat that they will
ultimately have to go with 5.1.

So, I have a set of questions.

1. Is there another way that I can set the include path globally for my
site? (Adding them to htaccess throws a 500 server error.)

2. How much security is really gained by moving sensitive include files
out of the site path (my include files all use the .php extension)?
Should I even be that concerned about this capability?

3. Would I gain the same security if I changed my current include files
(which I would have to put back into the public site path) to do nothing
but set include_path outside the public site and then include a new,
secondary file which actually contains the sensitive data?

4. Does anyone know why I *can* use local php.ini files in 5.01 and not
in 5.1?

--
*************** **************
Chuck Anderson • Boulder, CO
http://www.CycleTourist.com
*************** **************

[Jesper H.]

On 2006-08-07, Chuck Anderson wrote:

1. Is there another way that I can set the include path globally for
my site? (Adding them to htaccess throws a 500 server error.)

Like this?

php_value include_path "whatever"

If it doesn't work, then a vague part of my memory says that Apaches
AllowOverride directive might be the problem. Unfortunately I don't
remember the minimal setting needed for php_value and such to work. You
would need to contact the admins to have it changed.

2. How much security is really gained by moving sensitive include
files out of the site path (my include files all use the .php
extension)? Should I even be that concerned about this capability?

The only potential risk I can see is if the admins accidently disable
PHP processing, e.g. while updating some configuration files. So I'd say
it depends on how competent and alert the admins are. Still, even with
good admins, I'd better be safe than sorry.

3. Would I gain the same security if I changed my current include
files (which I would have to put back into the public site path) to do
nothing but set include_path outside the public site and then include
a new, secondary file which actually contains the sensitive data?

As far as I can tell, it would give you almost the same security. Again
the only potential problem I can see is accidently disabling PHP which
you let your users see the filenames you're including. Then they'd have
a more accurate idea of where to look, in the non public parts of the
server. But at least now they'd have to somehow get local access, as
well as overriding the permissions that prevent users from peeking at
each others files (.. you do have permissions set like that, right?).

--
|\_/| ,(Meow) Jesper H. <xy***********@ xyborx.dk>
(^.^)
`^' Sanity is an illusion

[Chuck Anderson]

Jesper H. wrote:

On 2006-08-07, Chuck Anderson wrote:

>1. Is there another way that I can set the include path globally for
my site? (Adding them to htaccess throws a 500 server error.)

Like this?

php_value include_path "whatever"

Yep.

If it doesn't work, then a vague part of my memory says that Apaches
AllowOverride directive might be the problem. Unfortunately I don't
remember the minimal setting needed for php_value and such to work. You
would need to contact the admins to have it changed.

I do not know what the issue is, but my host admin says it is not
possible with Php5.1 (?).

>

>2. How much security is really gained by moving sensitive include
files out of the site path (my include files all use the .php
extension)? Should I even be that concerned about this capability?

The only potential risk I can see is if the admins accidently disable
PHP processing, e.g. while updating some configuration files. So I'd say
it depends on how competent and alert the admins are. Still, even with
good admins, I'd better be safe than sorry.

That's the way I feel, too.

>

>3. Would I gain the same security if I changed my current include
files (which I would have to put back into the public site path) to do
nothing but set include_path outside the public site and then include
a new, secondary file which actually contains the sensitive data?

As far as I can tell, it would give you almost the same security. Again
the only potential problem I can see is accidently disabling PHP which
you let your users see the filenames you're including. Then they'd have
a more accurate idea of where to look, in the non public parts of the
server.

That's how I see it, but I want to be sure I'm not missing something. It
seems like the easiest "fix."

But at least now they'd have to somehow get local access, as
well as overriding the permissions that prevent users from peeking at
each others files (.. you do have permissions set like that, right?).

I've left most directory/file attributes at defaults, so you've prompted
me to play around and see if I can set these important folders to 700.
Everything still seems to still work, so thanks for that.

--
*************** **************
Chuck Anderson • Boulder, CO
http://www.CycleTourist.com
*************** **************