Project

General

Profile

Bug #8151

Reinstallation of dhcp package breaks proxy access to /etc/dhcp

Added by Dominic Cleal about 7 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
DHCP
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1156371

 [root@nightly ~]# ll /etc/dhcp -d
drwxr-xr-x. 3 root root 4096 Oct 22 08:02 /etc/dhcp

[root@nightly ~]# yum reinstall dhcp
...
Complete!

[root@nightly ~]# ll /etc/dhcp -d 
drwxr-x---. 3 root root 4096 Oct 24 05:16 /etc/dhcp 

[root@nightly ~]# service foreman-proxy restart
Stopping foreman-proxy:                                    [  OK  ]
Starting foreman-proxy:                                    [  OK  ]

[root@nightly ~]# curl -H "Accept:application/json" -k --cert /var/lib/puppet/ssl/certs/nightly.zzz.lan.pem --key /var/lib/puppet/ssl/private_keys/nightly.zzz.lan.pem https://nightly.zzz.lan:8443/dhcp/192.168.222.0
Unable to find the DHCP configuration or lease files

[root@nightly ~]# chmod o+x /etc/dhcp

[root@nightly ~]# curl -H "Accept:application/json" -k --cert /var/lib/puppet/ssl/certs/nightly.zzz.lan.pem --key /var/lib/puppet/ssl/private_keys/nightly.zzz.lan.pem https://nightly.zzz.lan:8443/dhcp/192.168.222.0
{"leases":[],"reservations":[]}

Therefore the workaround is to do chmod o+x /etc/dhcp in the sysvinit/systemd startup script of the proxy.

QA: To verify the bug, use the scenario above, plus make sure the foreman installer in dry run (-n) does not print any other planned changes:

[root@nightly ~]# foreman-installer -v -n
...
[ WARN 2014-10-24 06:07:35 verbose]  /File[/etc/dhcp]/mode: current_value 0751, should be 0755 (noop)
...

Also try to reinstall other software to verify similar scenarios: dhcp, bind, tftp, puppet, bmc/ipmi, facter.

For the record, there are more of these:

yum reinstall dhcp bind tftp-server puppet facter

Then:

[ WARN 2014-10-24 08:58:18 verbose]  /File[/var/named/dynamic]/mode: current_value 0770, should be 0750 (noop)
[ WARN 2014-10-24 08:58:19 verbose]  /File[/etc/dhcp]/mode: current_value 0750, should be 0755 (noop)

History

#1 Updated by Dominic Cleal about 7 years ago

  • Description updated (diff)
  • Category set to DHCP

I'm unsure about putting this in an init script or package (could use a trigger), as it's introduced by the installer configuration. Maybe there's a better long term solution that doesn't involve reading /etc/dhcp too?

Maybe it should be raised as a BZ in Fedora against the package and work from there, as the Debian package ships with 0755 permissions.

#2 Updated by Lukas Zapletal about 7 years ago

Indeed its nicer to have it fixed but I do not think this is rhelbackportable. Thus we need a hack too. Trigger sounds better. Lets raise the Fedora BZ first with a request for a group.

#3 Updated by Joshua Hoblitt about 7 years ago

I've had trouble with package updates on el6 breaking the permissions on dhcpd.conf as well. It's an ugly hack but I've resorted to setting the immutable xattr.

$ lsattr /etc/dhcp/dhcpd.conf
----i--------e- /etc/dhcp/dhcpd.conf

The omapi protocol makes my head explode but I believe it's not possible to query for all objects of a given type, which is why dhcpd.conf is being parsed.

#4 Updated by Anonymous over 4 years ago

what's the status here? I guess there's not so much we can do without changing the dhcpd RPM

#5 Updated by Ewoud Kohl van Wijngaarden over 3 years ago

  • Status changed from New to Resolved

In https://github.com/theforeman/puppet-foreman_proxy/commit/bde9c889a9bd2816df89483962852e37c5e39c29 we implemented a workaround of applying ACLs on EL systems (with a few later commits to fix some issues). That's the best we can do I think.

Also available in: Atom PDF