sssd won't start

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Thanks Alex!  I wasn't sure if it was important or not security-wise.

Rob

On 10/19/20 8:59 PM, Alex Murray wrote:
> CAUTION: This email originated from outside the Walla Walla University email system.
>
>
> Thanks for taking the time to report this bug and helping to make Ubuntu
> better. We appreciate the difficulties you are facing, but this appears
> to be a "regular" (non-security) bug. I have unmarked it as a security
> issue since this bug does not show evidence of allowing attackers to
> cross privilege boundaries nor directly cause loss of data/privacy.
> Please feel free to report any other bugs you may find.
>
> ** Information type changed from Private Security to Public
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.launchpad.net%2Fbugs%2F1900642&data=04%7C01%7CRob.Frohne%40wallawalla.edu%7C48bbf2f2338a4bad9e3b08d874ad667c%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C1%7C637387635392370790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2OJkI6yQF7a9iB3TllzWkAucjk8jdyEq6bJnJVK7YkI%3D&reserved=0
>
> Title:
> sssd won't start
>
> To manage notifications about this bug go to:
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.launchpad.net%2Fubuntu%2F%2Bsource%2Fsssd%2F%2Bbug%2F1900642%2F%2Bsubscriptions&data=04%7C01%7CRob.Frohne%40wallawalla.edu%7C48bbf2f2338a4bad9e3b08d874ad667c%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C1%7C637387635392380788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=K5OYVcp%2BLDI0R8vDQ42296%2BCKHOY2UW2WCsVJcJOSZE%3D&reserved=0

--
Rob Frohne, Ph.D. P.E.
E. F. Cross School of Engineering
Walla Walla University
100 SW 4th Street
College Place, WA 99362
(509) 527-2075

Here is a link to the startup messages.

https://photos.app.goo.gl/1Y9eKhtuhNXNpjVQ8

The sssd service is one handling Active Directory, is that a feature you opted in for during the installation?

sssd is installed by default now on groovy

the failure to start is mostly just noise, though there's a proposal to not even try to start if there's no conffile for it

This makes the default boot on livecd very ugly.

We must add conditions to the sssd.service to not attempt starting, if not configured.

@tjaalton where is this proposal? imho we must ship this for groovy.

need to test that above patch is enough, or if more units need the same guard.

I think SRUing would be OK for this one.

I upgraded from 20.04 to 20.10 and now my boot screen is littered with SSSD error messages. I don't even know what it is ;). Anyway, it would be preferrable to not having these messages if not needed.

Same bug for me. I applied the patch manually and it works for me !
Thanks @Dimitri John Ledkov (xnox) !

I may add something else. During sssd install there were several warning messages:

Configurando sssd-common (2.3.1-3) ...
Creating SSSD system user & group...
adduser: Aviso: El directorio personal «/var/lib/sss» no pertenece al usuario que está creando.
Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing complain mode
Warning from /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd line 54): Caching disabled for: 'usr.sbin.sssd' due to force complain

About the first warning "adduser: Aviso: El directorio personal «/var/lib/sss» no pertenece al usuario que está creando."
(translation: adduser: Warning: The personal directory «/var/lib/sss» doesn't belong to the user that is being created).

I can tell that it's true; the directory /var/lib/sss is owned by root instead of sssd.
All the directories and files inside /var/lib/sss are owned by sssd user except /var/lib/sss/deskprofile directory that is also owned by root.

Probably not a problem, but may be also patched.

I can't tell about the warning messages related to apparmor.

I have the same problem and I have disabled and removed / purged apparmor with all the dependencies,but the error persisted.In my case it happens only if I load the xen hypervisor.

I've just purged sssd with this command : apt-get purge --auto-remove sssd and it didn't work. I see the same errors as before.

I have the same problem. Some people found an workaround:

"SOLVED
# debug with
sudo sssd -d9 -i
# solution
sudo cp /usr/lib/x86_64-linux-gnu/sssd/conf/sssd.conf /etc/sssd/.
sudo chmod 600 /etc/sssd/sssd.conf"

source: https://ubuntuforums.org/showthread.php?t=2452209&p=13993643

In my case, I did this :
sudo ln -s /usr/lib/x86_64-linux-gnu/sssd/conf/sssd.conf /etc/sssd/sssd.conf

It work for me, but is it a "good/best practice" solution ?

Well it was not a good idea, I had to revert because boot was unstable: I get no more sssd error log but boot freeze almost every time before gdm (black screen)...

I finally had some time to do some investigation on this bug. I appreciate the analysis done by others, and the patch provided by Dimitri.

I verified that using ConditionPathExists on sssd.service does prevent sssd from starting (as expected), which means that the error messages in the log are gone.

sssd has a lot of services and socket-activated units associate with it, but all of them are ultimately bound (via systemd's BindsTo and After directives) to sssd.service, which means that they will not start unless sssd.service also starts. As such, and to avoid redundancy, I think it is better to modify only sssd.service. This has the "downside" that the user will still see warning messages (not errors) in the logs, like:

Dec 09 18:44:29 focal-desktop systemd[1]: sssd-nss.socket: Bound to unit sssd.service, but unit isn't active.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD NSS Service responder socket.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-nss.socket: Job sssd-nss.socket/start failed with result 'dependency'.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-autofs.socket: Bound to unit sssd.service, but unit isn't active.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD AutoFS Service responder socket.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-autofs.socket: Job sssd-autofs.socket/start failed with result 'dependency'.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-pac.socket: Bound to unit sssd.service, but unit isn't active.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD PAC Service responder socket.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-pac.socket: Job sssd-pac.socket/start failed with result 'dependency'.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-pam-priv.socket: Bound to unit sssd.service, but unit isn't active.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD PAM Service responder private socket.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD PAM Service responder socket.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result 'dependency'.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-pam-priv.socket: Job sssd-pam-priv.socket/start failed with result 'dependency'.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-ssh.socket: Bound to unit sssd.service, but unit isn't active.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD SSH Service responder socket.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-ssh.socket: Job sssd-ssh.socket/start failed with result 'dependency'.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-sudo.socket: Bound to unit sssd.service, but unit isn't active.
Dec 09 18:44:29 focal-desktop systemd[1]: Dependency failed for SSSD Sudo Service responder socket.
Dec 09 18:44:29 focal-desktop systemd[1]: sssd-sudo.socket: Job sssd-sudo.socket/start failed with result 'dependency'.

I think this is fine, though, because, as I said above, these are just warnings.

I am going to prepare an upload with the systemd change mentioned above, and will perform more tests to verify that everything works OK. Hopefully I will be able t...

I'm thinking that enabling socket activation was a mistake, as no other distro I know of (besides Debian etc) do that. It also requires patching adcli and freeipa to not put "services = ..." line on the sssd.conf or it would fail to start.

I've uploaded 2.4.0-1 to unstable and probably will drop socket activation in the next upload well before bullseye is frozen.

@Timo thanks for looking into that. FWIW, I've just opened a MR on salsa in order to propose this change to the Debian sssd as well:

https://salsa.debian.org/sssd-team/sssd/-/merge_requests/10

This bug was fixed in the package sssd - 2.4.0-1ubuntu1

---------------
sssd (2.4.0-1ubuntu1) hirsute; urgency=medium

  * d/p/condition-path-exists-sssd-conf.patch: Only start
    sssd.service if there is a configuration file present.
    (LP: #1900642)

 -- Sergio Durigan Junior <email address hidden> Thu, 10 Dec 2020 14:20:24 -0500

Hello Rob, or anyone else affected,

Accepted sssd into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.3.1-3ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello
See these return

$ sudo apt update
Atteint :1 http://fr.archive.ubuntu.com/ubuntu groovy InRelease
Atteint :2 http://fr.archive.ubuntu.com/ubuntu groovy-updates InRelease
Atteint :3 http://security.ubuntu.com/ubuntu groovy-security InRelease
Atteint :4 http://fr.archive.ubuntu.com/ubuntu groovy-backports InRelease
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Tous les paquets sont à jour.

journalctl -b -p err
-- Logs begin at Wed 2020-10-07 09:43:17 CEST, end at Thu 2020-12-24 11:15:48 CET. --
déc. 24 11:10:46 a systemd[1]: Timed out waiting for device /dev/disk/by-uuid/db029e9d-4bc9-4e6e-8fd8-c860d4457331.
déc. 24 11:10:54 a sssd[995]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:10:54 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:10:55 a sssd[1115]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:10:55 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:10:56 a sssd[1122]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:10:56 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:10:57 a sssd[1126]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:10:57 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:10:58 a sssd[1134]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:10:58 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:10:59 a sssd[1142]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:10:59 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:11:00 a wpa_supplicant[1001]: nl80211: kernel reports: key not allowed
déc. 24 11:11:00 a sssd[1151]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:11:00 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:11:01 a sssd[1187]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:11:01 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:11:02 a sssd[1195]: SSSD couldn't load the configuration database [2]: No such file or directory.
déc. 24 11:11:02 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:11:02 a systemd[1]: Failed to start System Security Services Daemon.
déc. 24 11:15:21 a sudo[3318]: a : problem with defaults entries ; TTY=pts/0 ; PWD=/home/a ; USER=root ;

cat /etc/os-release
NAME="Ubuntu"
VERSION="20.10 (Groovy Gorilla)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.10"
VERSION_ID="20.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy

Brian, thanks so much for accepting the SRU so quick! As it turns out, I was able to come up with a better, more complete fix, and upstream has accepted it a few days ago. For that reason, and after consulting with Robie, I am dropping the verification-* tags from this bug, and will prepare a new upload containing the fix I mentioned.

Ah, and I received a report from user saying that he would like this fix to land in Focal as well, so I will prepare an upload for it as well.

OK, packages uploaded for Groovy and Focal (waiting on the SRU team now), and Hirsute.

I agree with the better fix of also covering /etc/sssd/conf.d in the condition, and taking the upstream patch is the best way of reducing the maintenance burden in Hirsute.

For Focal and Groovy, I'd normally expect a more minimal fix of just patching the service file, rather than the increased complexity of the conditional build, given that we know what the answer to the condition is on Ubuntu and that we usually aim for the most minimal fix. However in this case we can easily verify the outcome of the conditional build and that'll happen via SRU verification automatically, so I'm accepting it.

Hello Rob, or anyone else affected,

Accepted sssd into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.3.1-3ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Rob, or anyone else affected,

Accepted sssd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.2.3-3ubuntu0.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Verification for Focal:

root@focal-desktop:~# apt policy sssd
sssd:
  Installed: 2.2.3-3ubuntu0.1
  Candidate: 2.2.3-3ubuntu0.1
  Version table:
 *** 2.2.3-3ubuntu0.1 500
        500 http://ca.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.3-3 500
        500 http://ca.archive.ubuntu.com/ubuntu focal/main amd64 Packages

Booting the VM and verifying that the bug exists:

root@focal-desktop:~# journalctl -u sssd.service --boot 0
Jan 15 13:20:14 focal-desktop systemd[1]: Starting System Security Services Daemon...
Jan 15 13:20:14 focal-desktop sssd[655]: SSSD couldn't load the configuration database [2]: No such file or directory.
Jan 15 13:20:14 focal-desktop systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 15 13:20:14 focal-desktop systemd[1]: sssd.service: Failed with result 'exit-code'.
Jan 15 13:20:14 focal-desktop systemd[1]: Failed to start System Security Services Daemon.
Jan 15 13:20:14 focal-desktop systemd[1]: sssd.service: Scheduled restart job, restart counter is at 1.
Jan 15 13:20:14 focal-desktop systemd[1]: Stopped System Security Services Daemon.
...

Installing the proposed package and verifying that it solves the problem:

root@focal-desktop:~# apt policy sssd
sssd:
  Installed: 2.2.3-3ubuntu0.2
  Candidate: 2.2.3-3ubuntu0.2
  Version table:
 *** 2.2.3-3ubuntu0.2 500
        500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.3-3ubuntu0.1 500
        500 http://ca.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
     2.2.3-3 500
        500 http://ca.archive.ubuntu.com/ubuntu focal/main amd64 Packages

root@focal-desktop:~# journalctl -u sssd.service --boot 0
-- Logs begin at Tue 2020-12-08 17:53:54 EST, end at Fri 2021-01-15 13:23:18 EST. --
Jan 15 13:23:07 focal-desktop systemd[1]: Condition check resulted in System Security Services Daemon being skipped.

Therefore, the service was correctly skipped because there is no configuration file present.

Verification done for Focal.

Verification for Groovy.

root@groovy-desktop:~# apt policy sssd
sssd:
  Installed: 2.3.1-3
  Candidate: 2.3.1-3
  Version table:
 *** 2.3.1-3 500
        500 http://ca.archive.ubuntu.com/ubuntu groovy/main amd64 Packages
        100 /var/lib/dpkg/status

Booting the VM and verifying that the bug exists:

root@groovy-desktop:~# journalctl -u sssd.service --boot 0
Jan 15 13:26:21 groovy-desktop systemd[1]: Starting System Security Services Daemon...
Jan 15 13:26:21 groovy-desktop sssd[641]: SSSD couldn't load the configuration database [2]: No such file or directory.
Jan 15 13:26:21 groovy-desktop systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 15 13:26:21 groovy-desktop systemd[1]: sssd.service: Failed with result 'exit-code'.
Jan 15 13:26:21 groovy-desktop systemd[1]: Failed to start System Security Services Daemon.
Jan 15 13:26:21 groovy-desktop systemd[1]: sssd.service: Scheduled restart job, restart counter is at 1.
Jan 15 13:26:21 groovy-desktop systemd[1]: Stopped System Security Services Daemon.
...

Installing the proposed package and verifying that it solves the problem:

root@groovy-desktop:~# apt policy sssd
sssd:
  Installed: 2.3.1-3ubuntu2
  Candidate: 2.3.1-3ubuntu2
  Version table:
 *** 2.3.1-3ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3.1-3 500
        500 http://ca.archive.ubuntu.com/ubuntu groovy/main amd64 Packages

root@groovy-desktop:~# journalctl -u sssd.service --boot 0
-- Logs begin at Wed 2020-12-09 18:34:32 EST, end at Fri 2021-01-15 13:28:44 EST. --
Jan 15 13:28:32 groovy-desktop systemd[1]: Condition check resulted in System Security Services Daemon being skipped.

Therefore, the service was correctly skipped because there is no configuration file present.

Verification done for Groovy.

This bug was fixed in the package sssd - 2.3.1-3ubuntu2

---------------
sssd (2.3.1-3ubuntu2) groovy; urgency=medium

  * d/p/0003-Only-start-sssd.service-if-there-s-a-configuration-f.patch:
    Upstream patch to make sssd.service only able to start when there
    is a configuration file present. (LP: #1900642)
  * d/p/condition-path-exists-sssd-conf.patch: Remove.

 -- Sergio Durigan Junior <email address hidden> Mon, 11 Jan 2021 14:30:55 -0500

The verification of the Stable Release Update for sssd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package sssd - 2.2.3-3ubuntu0.2

---------------
sssd (2.2.3-3ubuntu0.2) focal; urgency=medium

  * d/p/0003-Only-start-sssd.service-if-there-s-a-configuration-f.patch:
    Upstream patch to make sssd.service only able to start when there
    is a configuration file present. (LP: #1900642)

 -- Sergio Durigan Junior <email address hidden> Mon, 11 Jan 2021 14:33:54 -0500