Skip to content

Permissions changes introduced with SSSD 2.10.0 break SSSD

In 2.10.0, SSSD introduced the capability to be effectively dropped to a less privileged sssd user for most operations. This was reflected in the package when it was introduced to Arch, but with several problems:

  1. Permissions on variable folders and configs. While the package introduced an sssd user and the systemd service shipped with the package will chown all files in the database locations and log folders to that user, it crucially does not change the owner of any of the folders. /var/log/sssd and /var/lib/sss are both owned by root as before causing sssd to fail to be able to create the log files if they do not already exist. Similarly, upstream wants /etc/sssd/sssd.conf as follows

Important note: owner of /etc/sssd/sssd.conf file (and snippets) should match the user configured to start SSSD service.

which currently is not the case.

  1. /usr/lib/sssd/sssd/sssd_pam is not world executable. Previously this subsystem was launched by root, but now it would need to be started by the sssd user, while only being executable by root.

  2. /run/sssd.pid cannot be written by the sssd user.

I have verified that all permissions described here are set as such in the package itself and that my system is consistent with all package permissions.

Edited by Christian
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information