Re: A patch to keep cache directory out of webroot

Jason Judge wrote:
> "Jonn Beames" <[email protected]> wrote in message
> news:[email protected]...
> 
>>mikespub wrote:
>>
>>>In article <[email protected]>, Jonn Beames
> 
> <[email protected]>
> 
>>>wrote:
>>>
>>>
>>>>...
>>>>If the "public" var/something/whatever needs to be writable, there's no
>>>>point in having a "private" var somewhere else.  What about, instead of
>>>>creating an new API and rewriting mods to use it, we rewrite the mods to
>>>>support a xarCoreGetVarDirPath() compatible, movable var directory?
>>>>
>>>>- Jonn
>>>
>>>
>>>Here I'm talking about content that needs to be :
>>>a) writeable by the web server,
>>>and
>>>b) accessible by the web clients
>>>
>>
>>The exact case we are trying to eliminate.  Unless it does not need to
>>be eliminated - see Alla's posts in this thread.
> 
> 
> It is not the only case we are trying to eliminate. Note that Alla's post
> refers to an incorrectly configured site. We could help here by providing a
> htaccess file in the public var directory to disable script running, or to
> limit access to certain types of files.

This is an excellent idea - example.htaccess file that shows a user how 
to protect their var directory.

Note, though, that Alla's post refers to a mis-configured Apache server 
or a default configured IIS server <- it sounds like IIS has a different 
security structure around the 'web server user"/anonymous user and 
webDAV integration from Apache.  The problem here can not be corrected 
with directives in a .htaccess file.
> 
> If we don't porivide a standard place to write web-readable files, then
> admins and developers will have to create their own. I think everyone going
> off and doing their own thing is going to open up far more security holes
> than one, well understood, well-explained and well-controlled directory.
> 
I completely agree that we need a standard, well understood/explained 
convention for writable files and accessing them.  It is what a var 
directory exists for.  I also believe, if a writable directory in the 
web root is a problem, then the whole allotment of writable directories 
should be movable with one, supported change.

If writable directories in the webroot is not an issue, then don't 
bother moving var and protect what you need to with .htaccess/config 
file directives.

> 
>>>Public and private wouldn't contain the same stuff - see discussion
>>>elsewhere :-)
>>>
>>>Mike.
>>
>>I'm not opposed to the idea of public and private var directories, I
>>just don't see a value-add.  On the contrary, it seems to add another
>>unnecessary complication to xaraya.
> 
> 
> Some files simply should not be accessible from the web interface. The user
> should not be able to even guess what their URLs are. Those files may be
> placed off the web root. The way the current modules are using var indicates
> that this is not so much an unnecessary complication, but a required feature
> that we are, at last, beginning to tackle.
> 
Agreed, some files written by the system should not be readable, even if 
there isn't a problem with writable directories in the webroot.  What 
I'm saying is that this is a different issue.  Yes, this issue is 
covered when the var directory is moved out of the webroot, but that 
doesn't mean solving the "writable directory in the webroot" problem 
needs to be inoculated to support solving the "some files shouldn't be 
accessed while still allowing writable directories to exist in the web 
root" problem.

> There may also be different quotas available in different file areas. I have
> one host, for example, where the off-site storage quota is quite large, and
> the on-site storage is expensive. The option to store the bulk of the files
> off the web space, on another disk even, is very attractive.
> 
> -- JJ
> 
> 

That's a good reason for supporting a public and private var directory: 
most of the writable files moved out, some left in, for storage 
management.  But, I don't see that as being a likely scenario people 
will encounter - your host will probably change the rule once they 
realize it does not achieve anything.  And, it doesn't change the fact 
that this is a different issue.

  - Jonn