hi kai,
On Wed, Jun 29, 2005 at 12:25:37PM +1000, Kai Hendry wrote:
> On Tue, Jun 28, 2005 at 11:58:10AM +0100, Neil McGovern wrote:
> > > PHP includes usually sit in the www accessible directory. This might be
> > > confusing.
> > They shouldn't, it's a security risk to have these things publically
> > accessable. Things which don't HAVE to be in the doc root, shoudn't be.
> > See http://lists.debian.org/debian-security/2005/04/msg00103.html
>
> See http://lists.debian.org/debian-security/2005/04/msg00104.html
> And http://lists.debian.org/debian-security/2005/04/msg00111.html
>
> I don't think it is such a big issue either.
actually, you're misreading the first mail. in the first mail, someone
was asking if moving includes out was cause for a DSA, which it
certainly isn't. at the end of the mail, there's an example of exactly
why moving include files out of the document root is a good thing (a
security bug related to cross-site scripting using such include files).
this issue isn't a black and white issue, though, because what constitutes
a file and a library can be kind of vague at times. it may be that we
back down from calling this a policy requirement but merely a 'best
practice'.
> It will require some magic/work to make Wordpress upstream code to look
> in the right place if I have to move includes/ to another directory.
it's not too hard for most php applications. if a central config file
exists, you can patch in something like:
ini_set('include_path',
'/usr/share/wordpress/include:' . ini_get('include_path'));
if not, you can do something similar in the apache.conf, using
php_value or php_auto_prepend to get such a thing in there.
> Data stores should be ideally maintained in the mysql-server. Else setup
> by the Web application IMO. Not by Debian scripts.
i think you misunderstood what i meant by the purpose of this directory.
rdbms data goes in the rdbms, outside of the scope of what we're
discussing. however, there may exist other static data installed with
the package, such as xml definitions etc which would want to go into
somewhere under /usr/share/foo but not in the web root. but i think
at this point you understand the general idea of freeing up
/usr/share/foo for other things by placing the webroot in a
subdirectory.
sean
--
Attachment:
signature.asc
Description: Digital signature