[Bug 1195244] New: Mis-configured logging mutes log messages
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1195244
Bug ID: 1195244
Summary: Mis-configured logging mutes log messages
Product: Fedora
Version: 22
Component: javapackages-tools
Assignee: mizdebsk(a)redhat.com
Reporter: leamas.alec(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mat.booth(a)redhat.com, mizdebsk(a)redhat.com,
msimacek(a)redhat.com, msrb(a)redhat.com
Created attachment 994371
--> https://bugzilla.redhat.com/attachment.cgi?id=994371&action=edit
Test case provoking bug with non-readable metadata.
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Install DecodeIrCaller from
https://copr.fedoraproject.org/coprs/leamas/harctoolbox/
2. For the example, create a bug:
$ sudo chmod 600 /usr/share/maven-metadata/DecodeIrCaller.xml
3.Run attached maven.req. It is a patched version of the thing
run by rpmbuild
$ ./maven.req
4. Watch in output
Processing files: IrpMaster-1.0.2-1.fc21.noarch
No handlers could be found for logger "pyxb.binding.basis"
No handlers could be found for logger "pyxb.binding.basis"
The messages stems from the XML parsing in
javapackages/metadata/pyxbmetadata.py around line 59. Obviously, they are not
really helpful, loggers should be configure
Actual results:
Useless messages
Expected results:
Good messages.
Additional info:
Same thing is likely to happen for any maven-driver spec given a non-readable
metadata dependency. And there are other things which might got wrong, needing
configured logger I guess.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=AcTChb0Kzb&a=cc_unsubscribe
8 years, 4 months
[Bug 1258515] New: jenkins: CSFR vulnerability allowing remote attacker to hijack authentication
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1258515
Bug ID: 1258515
Summary: jenkins: CSFR vulnerability allowing remote attacker
to hijack authentication
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: high
Priority: high
Assignee: security-response-team(a)redhat.com
Reporter: amaris(a)redhat.com
CC: bleanhar(a)redhat.com, ccoleman(a)redhat.com,
dmcphers(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
jdetiber(a)redhat.com, jialiu(a)redhat.com,
jkeck(a)redhat.com, joelsmith(a)redhat.com,
jokerman(a)redhat.com, kseifried(a)redhat.com,
lmeyer(a)redhat.com, logans(a)cottsay.net,
mizdebsk(a)redhat.com, mmccomas(a)redhat.com,
msrb(a)redhat.com
CSFR vulnerability in Jenkins 1.626 was found, allowing remote attackers to
hijack the authentication of users for most requests. It can be exploited to
change change specific settings or execute code.
Report (includes reproducers):
http://seclists.org/bugtraq/2015/Aug/161
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fjM9Fr9yWG&a=cc_unsubscribe
_______________________________________________
java-sig-commits mailing list
java-sig-commits(a)lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/java-sig-commits@lists.fedorapro...
8 years, 4 months
[Bug 1215690] New: [abrt] tomcat-7.0.59-1.fc21: Uncaught exception java.lang.NullPointerException in method org.apache.catalina.loader.WebappClassLoader.getResource()
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1215690
Bug ID: 1215690
Summary: [abrt] tomcat-7.0.59-1.fc21: Uncaught exception
java.lang.NullPointerException in method
org.apache.catalina.loader.WebappClassLoader.getResour
ce()
Product: Fedora
Version: 21
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: redhat(a)lb1a.de
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, coolsvap(a)gmail.com,
ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
Tried to reload the geonetwork-opensource webapp via the manager application.
This seemed to fail with endless identical error in the logfile, so i tried to
stop the tomcat server
[root@pazuzu]# service tomcat stop
Redirecting to /bin/systemctl stop tomcat.service
Then abrt popped up.
Version-Release number of selected component:
tomcat-7.0.59-1.fc21
Additional info:
reporter: libreport-2.3.0
abrt-java-connector: 1.0.10
cmdline: /usr/lib/jvm/jre/bin/java
-agentpath:/usr/lib/abrt-java-connector/libabrt-java-connector.so=abrt=on
-classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start
executable: /usr/share/tomcat/bin/bootstrap.jar
java_executable:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.45-31.b13.fc21.x86_64/jre/bin/java
kernel: 3.19.4-200.fc21.x86_64
pid: 12202
runlevel: N 5
uid: 91
Truncated backtrace:
#1 java.lang.NullPointerException
#2 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#3 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#4 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#5 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#6 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#7 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#8 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#9 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
#10 at
org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1466)
[file:/usr/share/java/tomcat/catalina.jar]
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Ox2leBR99N&a=cc_unsubscribe
8 years, 4 months
[Bug 1224515] New: default for tomcat temp folder should be multiple instances should be ${catalina.base}/temp
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1224515
Bug ID: 1224515
Summary: default for tomcat temp folder should be multiple
instances should be ${catalina.base}/temp
Product: Fedora
Version: 21
Component: tomcat
Severity: low
Assignee: ivan.afonichev(a)gmail.com
Reporter: edwardquick(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com, me(a)coolsvap.net
Description of problem:
When a user configures multiple instances of tomcat, the CATALINA_TMPDIR
setting is not updated to match the instance's temp folder.
Version-Release number of selected component (if applicable):
tomcat-7.0.59-1.fc21.noarch
How reproducible:
The default setting in /etc/tomcat/tomcat.conf is
# System-wide tmp
CATALINA_TMPDIR="/var/cache/tomcat/temp"
Steps to Reproduce:
1. systemctl enable tomcat(a)instance1.service
2. Create catalina base folders (and contents), conf, work, temp, webapps under
/var/lib/tomcats/instance1
3. systemctl start tomcat(a)instance1.service
Actual results:
In the tomcat instance1 process, the temp folder is specified as:
-Djava.io.tmpdir=/var/cache/tomcat/temp
Expected results:
The tomcat instance temp folder should be:
-Djava.io.tmpdir=/var/lib/tomcats/instance1/temp
Additional info:
Note we did nothing to configure LOGGING_PROPERTIES, yet the process correctly
specifies it as we expect
-Djava.util.logging.config.file=/var/lib/tomcats/instance1/conf/logging.properties
This issue is easily fixed with the followiing patch to
/usr/libexec/tomcat/preamble
# diff -u /usr/libexec/tomcat/preamble.orig /usr/libexec/tomcat/preamble
--- /usr/libexec/tomcat/preamble.orig 2015-05-23 23:10:14.979921192 +0100
+++ /usr/libexec/tomcat/preamble 2015-05-23 23:14:07.636951751 +0100
@@ -42,3 +42,11 @@
LOGGING_PROPERTIES="${CATALINA_HOME}/conf/logging.properties"
fi
fi
+
+if [ -z "$CATALINA_TMPDIR" ] ; then
+ CATALINA_TMPDIR="${CATALINA_BASE}/temp"
+ if [ ! -d "${CATALINA_TMPDIR}" ] ; then
+ CATALINA_TMPDIR="${CATALINA_HOME}/temp"
+ fi
+fi
+
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=niFb9Utlz4&a=cc_unsubscribe
8 years, 4 months