Hi,

the sssd.service as present on Debian/trixie automatically sets read
permissions for the group for all files within /etc/sssd/, and also
modifies ownership permissions of /var/lib/sss/ + /var/log/sssd/.

Example:

  # ls -la /etc/sssd/sssd.conf
   -rw------- 1 root root 3394 Aug  7 17:37 /etc/sssd/sssd.conf
  # systemctl restart sssd
  # ls -la /etc/sssd/sssd.conf
   -rw-r----- 1 root root 3394 Aug  7 17:37 /etc/sssd/sssd.conf

This is caused by /usr/lib/systemd/system/sssd.service with its:

  ExecStartPre=+-/bin/chown -f -R root:root /etc/sssd
  ExecStartPre=+-/bin/chmod -f -R g+r /etc/sssd
  ExecStartPre=+-/bin/sh -c "/bin/chown -f root:root /var/lib/sss/db/*.ldb"
  ExecStartPre=+-/bin/chown -f -R root:root /var/lib/sss/gpo_cache
  ExecStartPre=+-/bin/sh -c "/bin/chown -f root:root /var/log/sssd/*.log"

The underlying change is coming from
https://github.com/SSSD/sssd/commit/8db2df4fcbd09badafbc207bd4150b5f1cc2d5fb:

| commit 8db2df4fcbd09badafbc207bd4150b5f1cc2d5fb
| Author: Alexey Tikhonov <atikhono@redhat.com>
| Date:   Thu Oct 24 15:34:26 2024 +0200
|
|     Configuration: make sure /etc/sssd and everything
|
|     beneath is owned by 'sssd' group and readable by group.
|
|     This should allow for reasonable rw-r----- root:sssd
|
|     At some points those chown/chmod can be removed.
| [...]

IMO this is something that shouldn't be done at all, but especially
not something for Debian. If at all, such a behavior change *could*
be implemented in maintainer scripts for upgrades to run *once*, but
surely not within each service restart, overwriting any
permission/ownership changes implemented by the local administrator.
(It's especially annoying, as sssd even fails to start with the 0640
permissions on e.g. bookworm, and when deploying such a change via
configuration management, this now needs distribution specific
workarounds.)

regards
-mika-

Hello,
today, I was stumbling about this issue with Trixie.

Indeed, here, sssd.conf is managed by Ansible which ensures file
permissions are 0600 during each playbook execution following a restart
of the sssd service if sssd.conf has changed. As a result, the playbook
is reporting 2 changes each time which is misleading and requires a fix.

Some tests with systemd overrides have shown, that the new sssd in
Trixie happily accepts any permission for OWNER and GROUP, as long as
there is nothing configured for OTHERS, examples:
- good: 0400, 0440, 0600, 0640, 0660, etc.
- bad: 0444, 0644, 0664, 0666, etc.

I endorse the view of mika. Changing file permissions during each
service start is unexpected and not usual practice as far as I know.
These kind of settings should be documented and if at all, only executed
once during package installation and/or upgrade.

Besides, sssd is reporting wrong permissions just fine with a clear
error and does not start, same as before with bookworm.

In addition, the upstream commit is talking about giving read to a group
called 'sssd'. On my system, this group is existing, but it is not
utilized here (chown ... root:root...). Therefore, the additional read
permission for the group is more or less redundant.

The new behavior is forcing everybody with config mgmt tools to
implement a fix. With the old behavior there would be no change
necessary at all.

There is another issue. Let's say, someone decides that a group (of
users) should be allowed to edit sssd.conf. In this case, the desired
group write permissions would not persist and the only way to solve the
situation is to change the sssd service. Luckily, systemd allows doing
so with override files, but still, it would be a unnecessary burden.

I suggest to remove the 'ExecStartPre' settings again, even for the
Trixie stable release, because such a change would not break anything.

Thanks and Best Regards
Berni

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
upgrade to debian 13, trixie
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
changing the permissions to make sssd owner
   * What was the outcome of this action?
they are reset and then sssd fails to start because of bad permissions
   * What outcome did you expect instead?
running of sssd

*** End of the template - remove these template lines ***