[Bug 59942] tomat8.5 write logs with incorret os permission
https://bz.apache.org/bugzilla/show_bug.cgi?id=59942 jiucai changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |REMIND --- Comment #3 from jiucai --- finally, I found it at tomcat9.0 changelog http://tomcat.apache.org/tomcat-9.0-doc/changelog.html here: Tighten up the default file permissions for the .tar.gz distribution so no files or directories are world readable by default. Configure Tomcat to run with a default umask of 0027 which may be overridden by setting UMASK in setenv.sh. (markt) In Tomcat8.5.x and Tomcat9.0.x, at bin/catalina.sh there sets umask when tomcat started , becuase umask=0027, so files cerated by tomcat will be 640 and dirs will be 750. # Set UMASK unless it has been overridden if [ -z "$UMASK" ]; then UMASK="0027" fi umask $UMASK Now, When I start tomcat process, I set env var UMASK to 0022 will change back the way that log files created as tomcat8.0. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] tomcat issue #22: [Bug 58242] Scanning jars in classpath to get annotations ...
Github user cmx1 commented on the issue: https://github.com/apache/tomcat/pull/22 66 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59942] tomat8.5 write logs with incorret os permission
https://bz.apache.org/bugzilla/show_bug.cgi?id=59942 Chuck Caldarale changed: What|Removed |Added Resolution|REMIND |INVALID -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59950] New: Incorrect variables in upgradeHandler.pruneIncomplete log message
https://bz.apache.org/bugzilla/show_bug.cgi?id=59950
Bug ID: 59950
Summary: Incorrect variables in upgradeHandler.pruneIncomplete
log message
Product: Tomcat 8
Version: 8.5.x-trunk
Hardware: All
OS: All
Status: NEW
Severity: trivial
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: apa...@saintymail.com
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/java/org/apache/coyote/http2/LocalStrings.properties?view=markup#l107
The log message "upgradeHandler.pruneIncomplete" uses {0} twice instead of {0}
and {1}.
So you can't see how many streams were not pruned.
You can see here how two variables are passed in -
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java?view=markup#l1016
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59226] StandardJarScanner ignores jars in manifest Class-path header
https://bz.apache.org/bugzilla/show_bug.cgi?id=59226 --- Comment #12 from saschakarc...@gmx.de --- Just found an interesting problem: We're trying to migrate a bunch of webapps from tomcat 7 to 8.5.4 with the goal in mind not to change too much. Our Tomcat has got a whole bunch of 3rd party libraries in a separate folder which is loaded by the common (or shared) class loader (i.e. not in WEB-INF/lib). Since current version of StandardJarScanner now also follows the class-path in header in the JARs manifest.mf, it tries and fails to load all those additional JARS mentioned in the manifest. But we never hat these additional JARS in classpath and collecting them all is a bit of not so funny work although feasible. Don't get me wrong. I understand that following the class-path mentioned in the manifest.mf files is technically totally correct. But it somehow complicates migration of already existing apps. Wouldn't it be useful to have sort of "don't resolve class-path header" switch (with default FALSE) but giving the the option to do so? What do you guys thing? Or have I just missed an already existing workaround? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59226] StandardJarScanner ignores jars in manifest Class-path header
https://bz.apache.org/bugzilla/show_bug.cgi?id=59226 --- Comment #13 from Mark Thomas --- I haven't checked the code but you might be able to use jarsToSkip or a JarScanFilter to not scan them. Failing that, a new enhancement request to make the manifest processing option sounds reasonable. I'd avoid the double negative though and have processManifest (or similar) with a default of true. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59823] HttpServletRequest#authenticate does not invoke JASPIC SAM
https://bz.apache.org/bugzilla/show_bug.cgi?id=59823 --- Comment #4 from Arjan Tijms --- >true if AuthStatus.SUCCESS Is that also when a null is passed to the CallerPrincipalCallback? Since in that case the container will establish this unauthenticated identity (see http://docs.oracle.com/javaee/7/api/javax/security/auth/message/callback/CallerPrincipalCallback.html). This means HttpServletRequest.getUserPrincipal() will return a null. But the JavaDoc for the return value of HttpServletRequest#authenticate says "true when non-null values were or have been established as the values returned by getUserPrincipal, getRemoteUser, and getAuthType." -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
