[
https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754748#action_12754748
]
Clifford commented on HTTPCLIENT-876:
-------------------------------------
Hi Sebb and Ortwin, after analyzing this further, I believe the fault lies with
HC and not Tomcat. The security exception is trying to do a mkdir within this
directory:
/web/tomcat/work/hosting/dir.dotgreen.org/.../loader/META-INF/
which is in the Tomcat work directory for my site on my shared GoDaddy server.
The work directory is intended for Tomcat temporary files, not properties files.
The comment in VersionInfo line 42 states the purpose of the class as follows:
* Provides access to version information for HTTP components.
* Static methods are used to extract version information from property
* files that are automatically packaged with HTTP component release JARs.
The VersionInfo#getVersionInfo call to WebAppClassLoader#getResourceAsStream at
line 244 is:
InputStream is = clsldr.getResourceAsStream
(pckg.replace('.', '/') + "/" + VERSION_PROPERTY_FILE);
The file 'version.properties' included in httpclient-4.0.jar has a directory of:
/org/apache/http/client
If one wishes to read a file in the object code directory, I think one
shouldn't use the class loader (but I am not an Apache expert). It looks to be
an internal method for loading Java .class files. The javadoc is here:
http://tomcat.apache.org/tomcat-4.1-doc/catalina/docs/api/org/apache/catalina/loader/WebappClassLoader.html
As a Java/Tomcat-application programmer, what I would instead use is a call to
the standard Java Properties#load, for example:
properties.load(new FileInputStream("filename.properties"))
For the filename I would provide a project-relative directory, which I think is
correctly done by the above code. So in my view, the issue is that the wrong
class was called, it should be Properties not WebAppClassLoader. There was no
exception, because VersionInfo#getVersionInfo eats the exception (see line
256). My guess is that this was not properly tested because of that. That is
a second flaw in VersionInfo that ought to be fixed.
Lastly there should be a ReadMe in the package that says to install the
'pom.properties' file where the JAR is installed.
Please advise if you agree/disagree. --- 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
