[
https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754856#action_12754856
]
Ortwin Glück commented on HTTPCLIENT-876:
-----------------------------------------
Clifford,
The code that calls java.io.File.mkdir is Tomcat code (WebappClassLoader). We
are calling ClassLoader.getResourceAsStream through an interface (the
responsible classloader for loading this resource). We have no control over the
(Tomcat's) implementation. Personally, I find it stupid to call mkdir from a
ClassLoader (which should behave read-only anyway). We CAN NOT use filesystem
operations directly to obtain the properties file. Imagine the classloader uses
HTTP to load the classes from a webserver. In this case we have no physical
access to the file. Using the classloader to obtain the resource is correct.
Anyway the most we could do is to catch the AccessControlException in our code,
and fail gracefully. But for sure other libraries will fail as well if loading
resources is broken.
Again, please speak to the Tomcat project. Their classloader implementation is
broken.
> 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
