[Sssd-maintainers] [Bug 2334868] New: updating an existing system to sssd-2.10.1 causes sssd to fail with permissions issues

https://bugzilla.redhat.com/show_bug.cgi?id=2334868

Bug ID: 2334868
           Summary: updating an existing system to sssd-2.10.1 causes sssd
                    to fail with permissions issues
           Product: Fedora
           Version: 41
                OS: Linux
            Status: NEW
         Component: sssd
          Keywords: Upgrades
          Severity: medium
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
  Target Milestone: ---
    Classification: Fedora

[this is on a ostree system (Fedora 41 Kinoite)]

From what I can tell, the sssd permissions changed recently from root:sssd to
sssd:sssd, and there are subtle differences in the way the config directories
and config files are owned that cause the most recent update to fail.

The previous version (2.10.0) had /etc/sssd at mode 0700, owned by root:sssd.
Now that the service runs as sssd:sssd it is not able to access previous
configs in /etc/sssd and the daemon fails with a permissions error.

There are a couple of contributing factors to this update failure:

1. the three-way merge for /etc files done by ostree does not preserve file
permissions, and does not update directory permissions. When /usr/etc/sssd
changed from 0700 to 0750, this was not reflected in /etc/sssd.

2. the ExecStartPre= statements in sssd.service are a bit optimistic. The chown
and chmod commands don't work with the current service settings (User= and
Group=). They currently fail but this is masked by the '-f' option.

I was able to fix this on my local system by (1) commenting out the
ExecStartPre= statements and (2) moving them to a dependent service that runs
as root. I guess this could also be accomplished with
PermissionsStartOnly=true.

Reproducible: Always

Steps to Reproduce:
1. build up a system that uses sssd (fully-populated /etc/sssd/sssd.conf)
2. stop sssd
3. chmod 0700 /etc/sssd
4. chown root:sssd /etc/sssd
5. try to start sssd
Actual Results:  
sssd does not start, it is not able to correctly re-own the files and
directories it needs.

Here is the update report from the most recent ostree transaction

$ rpm-ostree db diff
ostree diff commit from: rollback deployment
(5796a4d9fbff9b2d0e28f34070e6958e0cfb5a1b3ab702fd1ed318ade3aa91ef)
ostree diff commit to:   booted deployment
(f07128cd02dc40fbe578714f095140f44e5986f98902783d00bbd837a0ed06d6)
Upgraded:
  cldr-emoji-annotation 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
  cldr-emoji-annotation-dtd 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
  ibus-typing-booster 2.27.1-1.fc41 -> 2.27.2-1.fc41
  intel-vpl-gpu-rt 24.3.4-1.fc41 -> 24.4.4-1.fc41
  libsss_certmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
  libsss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
  libsss_nss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
  libsss_sudo 2.10.0-2.fc41 -> 2.10.1-1.fc41
  libva-intel-media-driver 24.3.4-1.fc41 -> 24.4.4-1.fc41
  libvpl 1:2.13.0-1.fc41 -> 1:2.14.0-1.fc41
  libxml2 2.12.8-2.fc41 -> 2.12.9-1.fc41
  openjpeg 2.5.3-1.fc41 -> 2.5.3-2.fc41
  setup 2.15.0-5.fc41 -> 2.15.0-8.fc41
  sssd-client 2.10.0-2.fc41 -> 2.10.1-1.fc41
  sssd-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
  sssd-kcm 2.10.0-2.fc41 -> 2.10.1-1.fc41
  sssd-krb5-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
  sssd-ldap 2.10.0-2.fc41 -> 2.10.1-1.fc41
  sssd-nfs-idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41