Bug 1575845
| Summary: | Firewalld fails to start because polkit doesn't allow it to claim the dbus path | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jamie Lennox <jamielennox> |
| Component: | firewalld | Assignee: | Eric Garver <egarver> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.5 | CC: | Bwilsonhunt, evan.sikorski, foss, ibaldo, nick, RabidCicada, rkhan, todoleza, travneff |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-05-26 19:13:27 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: | |||
hmm, so i realized that i had started with a 7.3 image and apparently yum update had got it to 7.5 that lsb_release reported. I just tried again with the 7.5 image ami-67589505 and this time it seems to have worked. Not sure what you want to do here with the bug report. There would appear to be an upgrade issue that i'm probably not going to dig further into. (In reply to Jamie Lennox from comment #0) > Whatever is happening that causes firewalld in default configuration to not > have permissions to register on dbus and is preventing start. It's possible the policy file existed, but dbus-daemon didn't reload the policy. This can be done by sending it SIGHUP. However, I would expect that to occur when firewalld is installed/upgraded. > Firewalld is obviously returning a 0 exit status when it is failing and so > systemd doesn't know that the startup has failed. This failure to start > should return an error to systemd. Agree this is a bug. Looks like firewalld doesn't exit properly if there is a DBUS exception early in the startup process (run_server()). I will use this BZ to address the exit code issue. I'm also actually having the same issue, running on digital ocean from a fresh centos 7 image and running a simple yum update which upgrades to 7.5.
[root@brad-csgo-nl-001-worker etc]# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.5.1804 (Core)
Release: 7.5.1804
Codename: Core
[root@brad-csgo-nl-001-worker etc]# uname -a
Linux brad-csgo-nl-001-worker 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@brad-csgo-nl-001-worker etc]# systemctl status firewalld -l
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Tue 2018-05-15 19:03:37 BST; 8min ago
Docs: man:firewalld(1)
Main PID: 12018 (code=exited, status=0/SUCCESS)
May 15 19:03:37 brad-csgo-nl-001-worker systemd[1]: Starting firewalld - dynamic firewall daemon...
May 15 19:03:37 brad-csgo-nl-001-worker firewalld[12018]: ERROR: Exception DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.38" is not allowed to own the service "org.fedoraproject.FirewallD1" due to security policies in the configuration file
May 15 19:03:37 brad-csgo-nl-001-worker systemd[1]: Started firewalld - dynamic firewall daemon.
It works on the following setup with a fresh install (without yum update):
[root@centos-s-2vcpu-4gb-lon1-01 ~]# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.4.1708 (Core)
Release: 7.4.1708
Codename: Core
[root@centos-s-2vcpu-4gb-lon1-01 ~]# uname -a
Linux centos-s-2vcpu-4gb-lon1-01 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@centos-s-2vcpu-4gb-lon1-01 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-05-15 18:09:46 UTC; 2min 14s ago
Docs: man:firewalld(1)
Main PID: 10394 (firewalld)
CGroup: /system.slice/firewalld.service
└─10394 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
May 15 18:09:45 centos-s-2vcpu-4gb-lon1-01 systemd[1]: Starting firewalld - dynamic firewall daemon...
May 15 18:09:46 centos-s-2vcpu-4gb-lon1-01 systemd[1]: Started firewalld - dynamic firewall daemon.
Thanks for the info BradErz. I will try to reproduce. I've noticed a similar issue with going from 7.4 1704 DVD install to 7.5 1804 through yum update. Can anyone provide clarity on what the problem is? I'm having the same issue with 7.5, this broke our deployment script. Firewalld doesn't start on AWS, and our setup script changes the SSH port, which makes the server unreachable, because the firewall-cmd --permanent --zone=public --add-port=<new ssh port> fails. [root@server1 centos]# cat /var/log/messages |grep -i firewalld May 22 16:54:35 server1 yum[14382]: Installed: firewalld-filesystem-0.4.4.4-14.el7.noarch May 22 16:54:35 server1 yum[14382]: Installed: firewalld-0.4.4.4-14.el7.noarch May 22 16:54:41 server1 cloud-init: Package firewalld-0.4.4.4-14.el7.noarch already installed and latest version May 22 17:11:01 server1 systemd: Starting firewalld - dynamic firewall daemon... May 22 17:11:02 server1 firewalld[7025]: ERROR: Exception DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.73" is not allowed to own the service "org.fedoraproject.FirewallD1" due to security policies in the configuration file May 22 17:11:02 server1 systemd: Started firewalld - dynamic firewall daemon. May 22 17:11:22 server1 systemd: Starting firewalld - dynamic firewall daemon... May 22 17:11:22 server1 firewalld[7043]: ERROR: Exception DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.76" is not allowed to own the service "org.fedoraproject.FirewallD1" due to security policies in the configuration file May 22 17:11:22 server1 systemd: Started firewalld - dynamic firewall daemon. May 22 17:11:33 server1 cloud-init: FirewallD is not running May 22 17:11:33 server1 cloud-init: FirewallD is not running May 22 17:11:33 server1 cloud-init: FirewallD is not running May 22 17:11:34 server1 cloud-init: FirewallD is not running May 22 17:11:34 server1 cloud-init: FirewallD is not running May 22 17:11:34 server1 cloud-init: FirewallD is not running May 22 17:11:34 server1 cloud-init: FirewallD is not running May 22 17:11:35 server1 cloud-init: FirewallD is not running May 22 17:11:35 server1 cloud-init: FirewallD is not running I ran into this too. I could not solve it until I did the following # systemctl restart dbus # systemctl restart firewalld After that, it works. I can also confirm hitting this bug on CentOS 7.5.1804. I believe the base template I'm using was originally 7.3 as well, though. Thanks Evan for the fix! This did the trick for me too for the time being. I have tried to reproduce with with 7.3 and upgrading, but could not trigger the issue. It may be unique to deployment methods. The only way I could cause similar symptoms is by removing /etc/dbus-1/system.d/FirewallD.conf and starting firewalld. Given the reproducibility issue and simple workarounds (see below) I am closing this as WONTFIX. Workarounds: 1) systemctl restart dbus or 2) pkill -HUP dbus-daemon |
Description of problem: On AWS using a new install of RHEL 7 and trying to enable firewalld and the systemctl start command returns 0 as if success but firewalld is not started. If you invoke firewalld directly or check the status you see a message about polkit preventing firewalld from registering the dbus path. 2 Bugs here. Whatever is happening that causes firewalld in default configuration to not have permissions to register on dbus and is preventing start. Firewalld is obviously returning a 0 exit status when it is failing and so systemd doesn't know that the startup has failed. This failure to start should return an error to systemd. How reproducible: It's happened a few times in a row, so at least on this image very. setenforce 0 doesn't fix it. Steps to Reproduce: # yum update # yum install firewalld # systemctl start firewalld # lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 7.5 (Maipo) Release: 7.5 Codename: Maipo # uname -a Linux ip-10-25-200-141.localdomain 3.10.0-514.16.1.el7.x86_64 #1 SMP Fri Mar 10 13:12:32 EST 2017 x86_64 x86_64 x86_64 GNU/Linux # systemctl start firewalld # echo $? 0 # ps aux | grep firewall root 27327 0.0 0.0 112708 980 pts/0 S+ 01:15 0:00 grep --color=auto firewall # systemctl status firewalld -l ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2018-05-08 01:15:47 EDT; 24s ago Docs: man:firewalld(1) Process: 27324 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=0/SUCCESS) Main PID: 27324 (code=exited, status=0/SUCCESS) May 08 01:15:47 ip-10-25-200-141.localdomain systemd[1]: Starting firewalld - dynamic firewall daemon... May 08 01:15:47 ip-10-25-200-141.localdomain firewalld[27324]: ERROR: Exception DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.62" is not allowed to own the service "org.fedoraproject.FirewallD1" due to security policies in the configuration file May 08 01:15:47 ip-10-25-200-141.localdomain systemd[1]: Started firewalld - dynamic firewall daemon. Actual results: ERROR: Exception DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.62" is not allowed to own the service "org.fedoraproject.FirewallD1" due to security policies in the configuration file Expected results: Firewalld started. Additional info: I'm using the current supported RHEL 7 image on AWS which is ami-9c1b13ff (RHEL-7.3_HVM-20170424-x86_64-1-Hourly2-GP2). I have no idea if this is an AWS or RHEL issue.