[cowiki-dev] Re: [Issue 219] coWiki always keeps temporary files in htdocs

"Daniel T. Gorski" <[email protected]> Mon, 12 Sep 2005 21:03:41 +0200
Newsgroups gmane.comp.php.cowiki.devel
Message-ID <20050912190341.GM23827@bantha>
On 12 Sep 11:41, Paul Hanchett wrote:

> >>Daniel, please confirm if this is an issue.

> >If it is an issue, then it is not a coWiki, but a XAMPP issue. I have no
> >Windows here where I could check this XAMPP-thing.

> >>Is this a security vulnerability? 

> >Basically this is a security vulnerability, yes.

> >>Should the installer deal with setting this up (maybe it already does?)

> >What could be done by the installer, is to set the TEMP-path in the
> >core.conf file explicitly to the session path used by PHP internally
> >(session.save_path), which per definition should be always secure and not
> >reachable by an user agent.

> >Letting the user (and not an admin) to decide where the temporary files
> >should go, is basically not a good idea - stikes me. regards dtg

> Well, we have two types of users-- An admin who will be able to 
> configure paths as needed, and a user of a hosting service who may or 
> may not how enough rights.  Correct?

Correct.

> For example, my own ISP gives me a public_html where there is a virtual
> host configured.  How would I configure the temp directory outside of
> that?

You would also need an includes/ directory somewhere. So the
permissions/access would need to be set accordingly for a /tmp/ directory
then. Right.

As I said above: We take the PHP temporary directory where PHP saves its
sessions to save our temporary data too - the PHP session directory is
always configured and writable for the httpd or the PHP process; and it's
always out of the access of an user agent.

Different coWiki instances on the same machine won't interfere(!), even if
they use the same direcory for sessions, because coWiki uses different names
for its tmp-files which are unique for each installation on the same host.

As a side effect the [PATH] TEMP setting in core.conf would become
superfluous.

_OR_

we introduce a tmp/ directory in the same hierarchy where htdocs/, misc/ and
includes/ (or in future versions backup/) reside, like:

htdocs/
includes/
misc/
backup/
tmp/

In this case the installer could check the existence and accessibility of
such a directory, but it can not guarantee that this is not accessible by an
user agent due a misconfiguration of a user (wrong permission, symlink etc).

> I think the only way I could would be to create public_html/tmp and
> put a .htaccess that denied access to all-- RIght?

Possible, see above.
 
> This breaks down with the great variety of web servers coWiki is used 
> with-- not all seem to honor .htaccess.

Yes, this is a problem - I tend to the first solution, but I don't know how
to solve it elegantly if we _might_ need a backup/ directory in the future.
But this is an other story.

Thoughts?

regards dtg