Bug 38352 - Additional Entries for Default catalina.policy file.
Summary: Additional Entries for Default catalina.policy file.
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.14
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-22 20:27 UTC by George Sexton
Modified: 2009-07-05 16:09 UTC (History)
1 user (show)



Attachments
A diff file incorporating proposed changes. (1.57 KB, patch)
2006-01-22 20:28 UTC, George Sexton
Details | Diff
Simple JSP page to exibit the bug (480 bytes, text/plain)
2006-02-22 05:51 UTC, william.barker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description George Sexton 2006-01-22 20:27:46 UTC
This patch adds additional entries to the catalina.policy file. Specifically:

The catalina.base/shared directory is added and given equal permissions to
catalina.home/common

java.io.tmpdir is now readable.
javax.servlet.context.tempdir is now readable. I think to be compliant with the
spec, this must be allowed.

Directory specified by java.io.tmpdir (which is what tomcat points
javax.servlet.context.tempdir to) is now read, write, delete. Again, I think the
spec requires this.
Comment 1 George Sexton 2006-01-22 20:28:24 UTC
Created attachment 17486 [details]
A diff file incorporating proposed changes.
Comment 2 william.barker 2006-02-21 03:24:07 UTC
(In reply to comment #0)

Ok, lets see if I can get myself fired here ;-).

> This patch adds additional entries to the catalina.policy file. Specifically:
> The catalina.base/shared directory is added and given equal permissions to
> catalina.home/common

If it works for you, fine.  Change it in your copy.  However, in general 
${catalina.base}/shared will consist of untrusted code, so I don't think it's 
a good idea to trust it in the default policy file (which, by design, tries to 
be as strict as possible).

> java.io.tmpdir is now readable.

Don't see the need.  If you depend on this, your app is non-portable since 
there is no requirement that javax.servlet.context.tempdir has any relation to 
java.io.tmpdir.  In fact, a servlet container is perfectly free to set 
java.io.tmpdir to /dev/null if it wants.

> javax.servlet.context.tempdir is now readable. I think to be compliant with 
the
> spec, this must be allowed.

This is a request attribute, not a System attribute.  This does nothing.

> Directory specified by java.io.tmpdir (which is what tomcat points
> javax.servlet.context.tempdir to) is now read, write, delete. Again, I think 
the
> spec requires this.

Would need to research this one.  Like pretty much everybody else, I don't 
spend enough time testing with SM.
Comment 3 George Sexton 2006-02-21 18:51:20 UTC
Making java.io.tmpdir writable is fixing an implementation specific issue. The
spec says that the container MUST make temporary working directories available.

The IMPLEMENTATION that tomcat uses is to set javax.servlet.context.tempdir to
java.io.tempdir


So, my making that writable fixes an implementation specific issue for
tomcat. I'll say it again in case I wasn't clear.

1)	The spec says javax.servlet.context.tempdir must be a working
directory
2)	TOMCAT sets that value to the value of java.io.tmpdir

THEREFORE

FOR THE TOMCAT IMPLEMENTATION

java.io.tmpdir MUST BE WRITABLE.
Comment 4 George Sexton 2006-02-21 23:02:26 UTC
I was wrong. tempdir is not defined in terms of java.io.tmpdir. I apologize to
Bill whom I said was wrong and wrote an inflamatory and ill-advised message to.
Comment 5 william.barker 2006-02-22 05:51:07 UTC
Created attachment 17767 [details]
Simple JSP page to exibit the bug

Yes, you have a legitimate bug here. It is true that
javax.servlet.context.tempdir is not writable with the default catalina.policy
settings (in violation of the spec) when running with a SM.
Comment 6 Yoav Shapira 2006-12-24 18:06:05 UTC
So Bill and George, if I understand the result of your debate correctly, the
following lines from George's patch should be added to the default policy file:

permission java.util.PropertyPermission "java.io.tmpdir", "read";        
permission java.util.PropertyPermission "javax.servlet.context.tempdir", "read";	
permission java.io.FilePermission "${java.io.tmpdir}${file.separator}-", "read,
write, delete";

Is that right?
Comment 7 Mark Thomas 2009-06-19 06:06:24 UTC
Not quite.

The javax.servlet.context.tempdir is a context attribute rather than a system property. There is a complication that the name of the work directory varies per context and is not know when the policy file is parsed.

In trunk, 6.0.x and 5.5.x the WebappLoader sets the necessary permissions when it is started. However, the JasperLoader gets its permissions from the JspRuntimeContext that only gave a read permission for those files.

I have patched trunk to give JasperLoader read/write and proposed the fix for 6.0.x and 5.5.x
Comment 8 Mark Thomas 2009-06-19 06:06:51 UTC
Update status
Comment 9 Mark Thomas 2009-06-24 12:36:03 UTC
This has been fixed in 6.0.x and will be included in 6.0.21 onwards.
Comment 10 Mark Thomas 2009-07-05 16:09:11 UTC
This has been fixed in 5.5.x and will be included in 5.5.28 onwards