hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clifford (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HTTPCLIENT-876) Calling httpClient.execute(post) on a shared server causes security error (WRITE not allowed to protected area on disk)
Date Thu, 01 Oct 2009 16:11:23 GMT

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Clifford updated HTTPCLIENT-876:

Hi Ortwin and Sebb, I've researched the source code of Tomcat and found that it is doing the
correct thing (at least in my opinion).  In order to read the contents of the Properties file,
WebappClassLoader#findResourceInternal has to run UNZIP to extract the Properties file from
the HC jar. To do that, the below work directory is used by default for the extraction, which
does not exist and so the method tries to create the end 2 or more levels of directories (by
calling mkdirs):
(tomcat install location)/tomcat/work/hosting/(project)/_/loader/META-INF/

The Tomcat source code which does the above is shown on line 2004 on this Web site:

I contacted my hosting service, GoDaddy, and told them that their file security should be
changed on the above directory to allow WRITE's.  They declined to do that, and said that
I should upgrade to a dedicated server (which would cost me 10x as much per month).  I also
pointed out that (based on my research) it looks like not only the HttpClient but the JavaMail
library has this same problem.  So in the near future there will probably be hundreds of people
who run into this same problem (since GoDaddy has millions of clients).

So there is no way to solve/prevent this issue thru either Tomcat or GoDaddy.  But I recommend
one of two possible changes to the HttpClient library to 'avoid' the issue, in order of desirability
as follows:
    1. It is inefficient for a runtime library to "write 2+ new directories to disk (the first
time), plus call UNZIP which writes to a temporary file" each time an HTTP 'execute' request
is made.  Wouldn't it be better to move the Version# into a FINAL PUBLIC STATIC class (i.e.
a singleton)?
    2. Barring that (which may be infeasible due to HC design considerations I am not party
to), instead alter the call to WebappClassLoader#getResourceAsStream that fails, in VersionInfo#loadVersionInfo
line 244 where it calls getClassLoader, and put the call within a try{} clause, trap exceptions
and perhaps return 'null' for the version ... seems to me the lack of version# is not serious
enough to crash the whole 'AbstractHttpClient#execute operation

This is my last comment; the bug can stay closed unless one of you agrees that a change is
warranted.    --- Cliff

> Calling httpClient.execute(post) on a shared server causes security error (WRITE not
allowed to protected area on disk)
> -----------------------------------------------------------------------------------------------------------------------
>                 Key: HTTPCLIENT-876
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-876
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.0 Final
>         Environment: Java 5.0, Tomcat
>            Reporter: Clifford
>   Original Estimate: 4h
>  Remaining Estimate: 4h
> I run my JSP modules on a shared server at GoDaddy.com, one of the largest hosting companies
in the USA.  They have strict security on the servers which disallows writing to any disk
files unless they are in the /temp directory.
> When I first tried to execute a module I wrote using HttpClient, I got a security write-not-allowed
error.  I looked at the stack trace and found out that org.apache.http.impl.client.DefaultHttpClient.java
(at source line 197) calls org.apache.http.util.VersionInfo method loadVersionInfo, and that
class (at source line 248) tries to do a FILE WRITE after not finding a property file containing
the version#.  That WRITE is disallowed by my hosting, thus causing my HttpClient call to
fail.  I can provide more details if you like.
> I worked around the problem by commenting out the call to loadVersionInfo and recompiling
DefaultHttpClient, but MANY MANY programmers will run into this issue, so I would label it
an urgent bug that needs to be fixed.  Suggestions for the fix could be 1) hard-code the version
in a new final static variable of DefaultHttpClient, or 2) Write the Properties file containing
the HttpClient version# to a directory within /temp.
> The stack trace (transcribed from a printout) is:
> java.security.AccessControlException: access denied (java.io.FilePermission /web/tomcat/work/hosting/dir.dotgreen.org/.../loader/META-INF
write) at ... 5 levels of java.security.* then
> java.io.File.mkdir
> WebappClassLoader.findResourceInternal
> WebappClassLoader.findResource
> WebappClassLoader.getResourceAsStream
> VersionInfo.loadVersionInfo (line 244)
> DefaultHttpClient.createHttpParams (line 197)
> AbstractHttpClient.getParams (line 293)
> DefaultHttpClient.createClient (line 2)
> AbstractHttpClient.getConnectionManager (line 312)
> DefaultHttpClient.createHttpContext (line 254)
> AbstractHttpClient.execute (line 618)
> AbstractHttpClient.execute (line 576)
> AbstractHttpClient.execute (line 554)
> then a dozen JSP/catalina locations that are irrelevant

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message