You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Clifford (JIRA)" <ji...@apache.org> on 2009/09/09 23:30:22 UTC
[jira] Created: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
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
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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761259#action_12761259 ]
Ortwin Glück commented on HTTPCLIENT-876:
-----------------------------------------
see http://tomcat.apache.org/tomcat-5.5-doc/config/host.html workDir
> 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
[jira] Resolved: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ortwin Glück resolved HTTPCLIENT-876.
-------------------------------------
Resolution: Invalid
Please speak to the Tomcat project. There is nothing we can do here.
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Sam Berlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753280#action_12753280 ]
Sam Berlin commented on HTTPCLIENT-876:
---------------------------------------
This is not an error in HttpComponents. HC is just calling ClassLoader.getResourceAsStream. Tomcat's ClassLoader, WebappClassLoader, is trying to do a File.mkdir call while loading a resource. A quick google search for "WebappClassLoader.findResourceInternal write security" finds many people with similar problems. Presumably there's a solution, but it would be something specific to Tomcat, not HttpComponents.
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761258#action_12761258 ]
Ortwin Glück commented on HTTPCLIENT-876:
-----------------------------------------
So Tomcat tries to write to its designated working directory. And your webhoster denies access to that. Excuse me, but this setup is broken by design. You must give Tomcat a working directory that it may write to.
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Kiran Kumar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789793#action_12789793 ]
Kiran Kumar commented on HTTPCLIENT-876:
----------------------------------------
Hi Cliff,
Were you able to set up connection pooling on your Godaddy hosting environment using context.xml ? I have been trying this for around 10 days , but no luck . My environment Linux Shared Hosting with java supported
My directory structure
/WEB-INF/web.xml
/META-INF/context.xml
what I tried
1) Copied manually context.xml file under /META-INF , this didn't work
2) Created war file and deployed under root directory even this not helped me
3) context file parameters
<Context path="/" docBase=""
since I am copying under root folder , not sure with what names it creates under conf\Catalina\localhost .
Could you please help me ? ( Searching internet , talking to godaddy and trying to explain them the problem , almost stopped all my work)
Thanks for your help
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753360#action_12753360 ]
Sebb commented on HTTPCLIENT-876:
---------------------------------
When HC is run under Tomcat, it has to rely on the Tomcat classloader to find the properties file.
It so happens that the properties file contains version numbers, but it could contain message strings or whatever.
This is not a bug in HC.
> 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
[jira] Updated: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Clifford (JIRA)" <ji...@apache.org>.
[ 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:
http://www.docjar.com/html/api/org/apache/catalina/loader/WebappClassLoader.java.html
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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Clifford (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Clifford (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793445#action_12793445 ]
Clifford commented on HTTPCLIENT-876:
-------------------------------------
Sorry, I just saw your message lost in a storm of others. Did you get this
working? I did, but it wasn't easy.
--- 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Clifford (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753350#action_12753350 ]
Clifford commented on HTTPCLIENT-876:
-------------------------------------
I don't agree. If you examine the Google search results, none of them have
to do with determining the version#. That is specific to HC 4.0. I might
be wrong but I don't think so ... let me know.
--- 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
[jira] Closed: (HTTPCLIENT-876) Calling httpClient.execute(post) on
a shared server causes security error (WRITE not allowed to protected area
on disk)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb closed HTTPCLIENT-876.
---------------------------
I'll try once more.
The method ClassLoader#getResourceAsStream is a standard Java way to access resources contained within the application classpath, e.g. in the jar.
The method properties.load(new FileInputStream("filename.properties")) is fine for external files, but does not work for files contained within the application jar.
The version.properties file is included in each of the HC jar(s) and so the code uses ClassLoader#getResourceAsStream
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754862#action_12754862 ]
Sebb commented on HTTPCLIENT-876:
---------------------------------
One more suggestion - check that the application and supporting jars are correctly installed, and check that the HC jars actually contain version.properties.
Guessing from the name of the Tomcat method, it should only be called if the resource cannot be found in the normal locations (but I could be wrong).
I suggest you ask on the Tomcat user list.
It should be easy to create a very simple JSP that calls VersionInfo directly if they ask for a test case.
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761571#action_12761571 ]
Ortwin Glück commented on HTTPCLIENT-876:
-----------------------------------------
The interesting bit is "Configuring a Context workDir will override use of the Host workDir configuration".
And from http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
"Only if a context file does not exist for the application in the $CATALINA_HOME/conf/[enginename]/[hostname]/; in an individual file at /META-INF/context.xml inside the application files. If the web application is packaged as a WAR then /META-INF/context.xml will be copied to $CATALINA_HOME/conf/[enginename]/[hostname]/ and renamed to match the application's context path. Once this file exists, it will not be replaced if a new WAR with a newer /META-INF/context.xml is placed in the host's appBase."
Maybe you don't need GoDaddy's support :-)
> 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
[jira] Issue Comment Edited: (HTTPCLIENT-876) Calling
httpClient.execute(post) on a shared server causes security error (WRITE
not allowed to protected area on disk)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754862#action_12754862 ]
Sebb edited comment on HTTPCLIENT-876 at 9/14/09 1:09 AM:
----------------------------------------------------------
One more suggestion - check that the application and supporting jars are correctly installed, and check that the HC jars actually contain version.properties.
Guessing from the name of the Tomcat method, it should only be called if the resource cannot be found in the normal locations (but I could be wrong).
I suggest you ask on the Tomcat user list.
was (Author: sebb@apache.org):
One more suggestion - check that the application and supporting jars are correctly installed, and check that the HC jars actually contain version.properties.
Guessing from the name of the Tomcat method, it should only be called if the resource cannot be found in the normal locations (but I could be wrong).
I suggest you ask on the Tomcat user list.
It should be easy to create a very simple JSP that calls VersionInfo directly if they ask for a test case.
> 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
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-876) Calling httpClient.execute(post)
on a shared server causes security error (WRITE not allowed to protected
area on disk)
Posted by "Clifford (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761271#action_12761271 ]
Clifford commented on HTTPCLIENT-876:
-------------------------------------
Thanks Ortwin, I thought of that also, however the 'workdir' setting is in 'server.xml' in the (tomcat-home)/conf directory, which I don't have access to. On a shared server that directory is shared amongst all users, so can't be allowed to be changed by users.
But I will make another request from GoDaddy support, for them to set that parameter to /temp, which is one of the only directories on their shared server that is wide open to every process/user. I'll let you all know what happens.
p.s. On my own Tomcat development server at my house, this all works perfectly (since I don't secure any directories). So obviously a dedicated server (or cloud) would solve the problem. But again, that increases my monthly cost by 10x, and I have multiple GoDaddy accounts (not just one).
> 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