Bug 1755634
| Summary: | After upgrading to Fedore 31, PKI web UI use results in server error 500 w/ Java stacktrace | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Arno Lehmann <al> | ||||
| Component: | pki-core | Assignee: | Alex Scheel <ascheel> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 31 | CC: | alee, ascheel, csutherl, edewata, ftweedal, kwright, mharmsen, patdung100+redhat | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-11-24 20:00:10 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Arno Lehmann
2019-09-25 21:56:55 UTC
Hello, Any news regarding this bug? I had upgraded from FC30 to FC31 and having the same problem too. Hi, could you check the upgrade logs in /var/log/pki/pki-server-upgrade-*, are there any failures? Could you also try setting SECURITY_MANAGER="false" in both of these files? * /etc/sysconfig/pki-tomcat * /etc/pki/pki-tomcat/tomcat.conf Then restart the server. Thanks. For my case: /var/log/pki/pki-server-upgrade-* looks fine for the upgrade. After setting SECURITY_MANAGER=false in those files, the pki-tomcat can startup and the CA function looks okay now. Thanks, Patrick. The AccessControlException was triggered when the Eclipse JDT tried to read a system property. The permission for that should have been configured in /var/lib/pki/pki-tomcat/conf/catalina.policy, but for some reason it no longer works. Could you attach the catalina.policy? Could you also provide the output of these commands? $ ls -la /var/lib/pki/pki-tomcat/ $ ls -la /var/lib/pki/pki-tomcat/common/ Thanks. Created attachment 1632776 [details]
/var/lib/pki/pki-tomcat/conf/catalina.policy
/var/lib/pki/pki-tomcat/conf/catalina.policy
The policy was attached and the directory listing is in below. Thanks. # ls -la /var/lib/pki/pki-tomcat/ total 24 drwxrwx---. 6 pkiuser pkiuser 4096 Oct 5 21:15 . drwxr-xr-x. 3 root root 4096 Aug 15 09:04 .. lrwxrwxrwx. 1 pkiuser pkiuser 25 Aug 26 2018 alias -> /etc/pki/pki-tomcat/alias lrwxrwxrwx. 1 pkiuser pkiuser 21 Aug 26 2018 bin -> /usr/share/tomcat/bin drwxrwx---. 5 pkiuser pkiuser 4096 Aug 26 2018 ca lrwxrwxrwx. 1 pkiuser pkiuser 28 Aug 26 2018 common -> /usr/share/pki/server/common lrwxrwxrwx. 1 pkiuser pkiuser 19 Aug 26 2018 conf -> /etc/pki/pki-tomcat lrwxrwxrwx. 1 pkiuser pkiuser 25 Oct 5 21:15 lib -> /usr/share/pki/server/lib lrwxrwxrwx. 1 pkiuser pkiuser 23 Aug 26 2018 logs -> /var/log/pki/pki-tomcat lrwxrwxrwx. 1 root root 16 Aug 26 2018 pki-tomcat -> /usr/sbin/tomcat drwxrwx---. 2 pkiuser pkiuser 4096 Aug 26 2018 temp drwxr-xr-x. 2 pkiuser pkiuser 4096 Aug 26 2018 webapps drwxrwx---. 3 pkiuser pkiuser 4096 Aug 26 2018 work # ls -la /var/lib/pki/pki-tomcat/common/ total 12 drwxr-xr-x 3 root root 4096 Aug 15 09:04 . drwxr-xr-x 9 root root 4096 Aug 15 09:04 .. drwxr-xr-x 2 root root 4096 Oct 30 05:26 lib Thanks for the info. So far everything seems normal, so I'm not sure what's causing the problem, and I don't have the environment to reproduce the problem. So for now the workaround is to disable the security manager as described in comment #2. This is interesting. I was able to reproduce this issue. After following comment #2, I was able to get the proper UI. Then, I reset the SECURITY_MANAGER="true" in both the files and restarted my server. Interestingly, the UI works as expected. Ok, it took me a while to notice that repsonses by mail were not added here... sorry for that. However, I can confirm that disabling the SECURITY_MANAGER fixed the issue. The upgrade logs show no failures, and no scriptlets run. The directory listings look kind of boring: [root@ca2 ~]# LANG=C ls -la /var/lib/pki/CA2/ ; LANG=C ls -la /var/lib/pki/CA2/common/ total 0 drwxrwx---. 7 pkiuser pkiuser 151 Sep 5 22:51 . drwxr-xr-x. 3 root root 17 Aug 15 03:04 .. lrwxrwxrwx. 1 root root 16 May 9 2017 CA2 -> /usr/sbin/tomcat lrwxrwxrwx. 1 pkiuser pkiuser 18 May 9 2017 alias -> /etc/pki/CA2/alias lrwxrwxrwx. 1 pkiuser pkiuser 21 May 9 2017 bin -> /usr/share/tomcat/bin drwxrwx---. 5 pkiuser pkiuser 104 May 9 2017 ca lrwxrwxrwx. 1 pkiuser pkiuser 28 May 9 2017 common -> /usr/share/pki/server/common lrwxrwxrwx. 1 pkiuser pkiuser 12 May 9 2017 conf -> /etc/pki/CA2 lrwxrwxrwx. 1 pkiuser pkiuser 25 Sep 5 22:51 lib -> /usr/share/pki/server/lib lrwxrwxrwx. 1 pkiuser pkiuser 16 May 9 2017 logs -> /var/log/pki/CA2 drwxrwx---. 3 pkiuser pkiuser 74 May 9 2017 ocsp drwxrwx---. 2 pkiuser pkiuser 6 May 9 2017 temp drwxr-xr-x. 2 pkiuser pkiuser 6 May 9 2017 webapps drwxrwx---. 3 pkiuser pkiuser 22 May 9 2017 work total 4 drwxr-xr-x. 3 root root 17 Aug 15 03:04 . drwxr-xr-x. 9 root root 96 Aug 15 03:04 .. drwxr-xr-x. 2 root root 4096 Sep 23 10:19 lib [root@ca2 ~]# Thanks for the advice leading to a solution! Arno I recently hit this. Dinesh, the reason re-enabling security manager works after disabling it is that the .class files are cached under /var/lib/pki/pki-tomcat/work/. If you remove the .class files, you hit the same problem. It is a very strange issue. Possibly related to https://bugzilla.redhat.com/show_bug.cgi?id=1347774. I can't find any occurrence of dubious varargs use in the intermediate .java files produced by Jasper, though. Thanks Fraser! :-) Another workaround is to edit /usr/share/pki/server/conf/pki.policy and add the missing policy line: https://github.com/dogtagpki/pki/pull/381/files Coty, I think Tomcat needs an update as well. Dinesh found the following that might've not made it upstream: https://src.fedoraproject.org/rpms/tomcat/blob/master/f/tomcat-9.0-catalina-policy.patch#_24 I think it needs to be updated with the new ecj path as well. Most of the other paths seem fine. Thanks for pointing this out! For some reason that patch hasn't even been used (I got tired of trying to find when it was last included in the specfile). I will update the new ECJ location and apply the patch to the policy (even though it seems nobody is using the security manager configuration) :) Btw, I updated the policy patch (https://src.fedoraproject.org/rpms/tomcat/c/8d1457151e21f1788f277ec8ed15c83dfd44e197?branch=master) a couple months ago and the fix has been in stable for a bit with no new complaints, so I assume it's fine. This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |