Bug 1575845 - Firewalld fails to start because polkit doesn't allow it to claim the dbus path
Summary: Firewalld fails to start because polkit doesn't allow it to claim the dbus path
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld
Version: 7.5
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Garver
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 05:41 UTC by Jamie Lennox
Modified: 2019-08-05 17:44 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Jamie Lennox 2018-05-08 05:41:02 UTC
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.

Comment 2 Jamie Lennox 2018-05-08 05:58:51 UTC
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.

Comment 3 Eric Garver 2018-05-08 13:17:08 UTC
(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.

Comment 4 BradErz 2018-05-15 18:16:11 UTC
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.

Comment 5 Eric Garver 2018-05-15 20:10:17 UTC
Thanks for the info BradErz. I will try to reproduce.

Comment 6 Kyle Stapp 2018-05-17 18:28:25 UTC
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?

Comment 7 Nick 2018-05-22 17:37:39 UTC
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

Comment 8 Evan Sikorski 2018-05-31 21:20:33 UTC
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.

Comment 9 Justin W. Flory 2018-11-28 02:28:54 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.