On Sunday 20 January 2008, you wrote:
Upstream has this in catalina.properties (in SVN, not yet released).
// To enable per context logging configuration, permit read
access to the appropriate file. // Be sure that the logging
configuration is secure before enabling such access // eg
Michael Koch wrote:
On Fri, Jan 18, 2008 at 12:44:11PM -0800, Alexander Hvostov wrote:
It could just catch the SecurityException while looking for
logging.properties and pretend that the file doesn't exist, possibly
after logging a message saying so.
Yes that would be the most nicest as
On Saturday 19 January 2008, Marcus Better wrote:
If the user creates that file then the security exception still gets
thrown, so it would be very confusing to pretend the file doesn't
exist. I'm not too happy about this idea.
In that case, we would need to grant FilePermission to read the
On Thursday 17 January 2008, Marcus Better wrote:
Yes, see #460839 where we deal with this for the tomcat5.5-webapps.
The stricter permissions are part of a tightened security policy. I
think our options are:
(i) Change JULI not to look for the logging.properties in those places
unless
Package: tomcat5.5
Version: 5.5.20-2etch1
Severity: important
As you know, in tomcat5.5
5.5.20-2etch1, /etc/tomcat5.5/policy.d/03catalina.policy contains more
restrictive permissions for JULI than was previously the case.
This causes uses of java.util.logging to break, at least in some
Processing commands for [EMAIL PROTECTED]:
found 461355 5.5.25-4
Bug#461355: tomcat5.5: More restrictive JULI permissions break
java.util.logging.
Bug marked as found in version 5.5.25-4.
found 461355 5.5.25-5
Bug#461355: tomcat5.5: More restrictive JULI permissions break
java.util.logging
found 461355 5.5.25-4
found 461355 5.5.25-5
thanks
Alexander Hvostov wrote:
As you know, in tomcat5.5
5.5.20-2etch1, /etc/tomcat5.5/policy.d/03catalina.policy contains more
restrictive permissions for JULI than was previously the case.
Yes, see #460839 where we deal with this for the
7 matches
Mail list logo