Description of problem: After upgrading rhvh-4.1-0.20180425.0 to rhvh-4.2.4.3-0.20180627 the host is unable to be ssh'd into by rhel idm accounts using sssd. The owner and group were changed from root:root to sssd:sssd Version-Release number of selected component (if applicable): 4.2-20180627.0.el7_5 sssd-1.16.0-19.el7_5.5.x86_64 sssd-ldap-1.16.0-19.el7_5.5.x86_64 How reproducible: everytime Steps to Reproduce: 1.created a /etc/sssd/sssd.conf wither root:root permissions 2.yum update Actual results: [root@RHVH ~]# ls -alt /etc/sssd/sssd.conf -rw-------. 1 sssd sssd 613 Jun 12 12:59 /etc/sssd/sssd.conf in messages ~~~ Jun 12 10:13:06 RHVH sssd: Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root. Jun 12 10:13:06 RHVH systemd: sssd.service: main process exited, code=exited, status=4/NOPERMISSION Jun 12 10:13:06 RHVH systemd: Unit sssd.service entered failed state. Jun 12 10:13:06 RHVH systemd: sssd.service failed. ~~~ Expected results: while upgrading, the sssd.conf file should have permissions for root:root Additional info: As a workaround: [root@RHVH ~]# chown root:root /etc/sssd/sssd.conf [root@RHVH ~]# ls -alt /etc/sssd/sssd.conf -rw-------. 1 root root 613 Jun 12 12:59 /etc/sssd/sssd.conf [root@RHVH ~]# systemctl start sssd
This has nothing to do with aaa-misc extension, Ryan could you please take a look at permissions of the file on node?
This is not Node. This is sssd-common: [root@localhost ~]# rpm -V sssd-common [root@localhost ~]# ls -l /etc/sssd/sssd.conf ls: cannot access /etc/sssd/sssd.conf: No such file or directory [root@localhost ~]# rpm -qf /etc/sssd/sssd.conf sssd-common-1.16.0-16.el7.x86_64 [root@localhost ~]# touch /etc/sssd/sssd.conf [root@localhost ~]# !ls ls -l /etc/sssd/sssd.conf -rw-r--r--. 1 root root 0 Jul 25 13:46 /etc/sssd/sssd.conf [root@localhost ~]# rpm -V sssd-common .M...UG.. c /etc/sssd/sssd.conf From the specfile: %ghost %attr(0600,sssd,sssd) %config(noreplace) %{_sysconfdir}/sssd/sssd.conf When Node updates, it's possible that userid and group IDs have drifted (since many systems accounts do not have deterministic ugids), and we fix this after updating. THe assumption here is that RPMs will own this properly. This is fixed in sssd upstream: https://src.fedoraproject.org/rpms/sssd/blob/f27/f/sssd.spec#_884 I'll file a bug against platform and block here.
*** Bug 1608515 has been marked as a duplicate of this bug. ***
QE can reproduce this issue. Test versions: # imgbase layout rhvh-4.1-0.20180425.0 +- rhvh-4.1-0.20180425.0+1 rhvh-4.2.4.3-0.20180627.0 +- rhvh-4.2.4.3-0.20180627.0+1 Test steps: 1. Install rhvh-4.1-0.20180425.0 2. Check and create file /etc/sssd/sssd.conf [root@dhcp-8-130 ~]# rpm -V sssd-common [root@dhcp-8-130 ~]# ls -l /etc/sssd/sssd.conf ls: cannot access /etc/sssd/sssd.conf: No such file or directory [root@dhcp-8-130 ~]# rpm -qf /etc/sssd/sssd.conf sssd-common-1.16.0-19.el7.x86_64 [root@dhcp-8-130 ~]# touch /etc/sssd/sssd.conf [root@dhcp-8-130 ~]# !ls ls -l /etc/sssd/sssd.conf -rw-r--r--. 1 root root 0 Nov 23 14:20 /etc/sssd/sssd.conf 3. Upgrade host to rhvh-4.2.4.3-0.20180627.0 4. Check /etc/sssd/sssd.conf #ls -l /etc/sssd/sssd.conf Test results: After step 4, [root@dhcp-8-130 ~]# ls -l /etc/sssd/sssd.conf -rw-------. 1 sssd sssd 0 Nov 23 15:29 /etc/sssd/sssd.conf Expected results: After step 4, The ownership of /etc/sssd/sssd.conf should be still root:root, which is same as step 2.
Moving to 4.3.2 not being identified as blocker for 4.3.1
Changing dependency from RHEL 7.7 bug to RHEL 7.6.z bug
Fixed in sssd-1.16.2-13.el7_6.8 which is included in redhat-virtualization-host-4.3-20190418.0.el7_6
The bug is fixed in redhat-virtualization-host-4.3-20190418.0.el7_6. Test version: # imgbase layout rhvh-4.1-0.20180425.0 +- rhvh-4.1-0.20180425.0+1 rhvh-4.3.0.6-0.20190418.0 +- rhvh-4.3.0.6-0.20190418.0+1 sssd-common-1.16.2-13.el7_6.8.x86_64 Test steps: Same as comment 4 Test results: After step 4, The ownership of /etc/sssd/sssd.conf is root:root, which is same as step 2. Moving the status to VERIFIED.
Move this bug to downstream.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:1116