sssd service fails to start in noble numbat

[James Paton-Smith]

On a fresh build of Ubuntu 24.04, attempting to run the sssd service is failing continuously with a systemd service 'timeout' error.

The same /etc/sssd/sssd.conf file is working in 20.04 and 22.04

I believe this issue is specifically related to the sssd systemd service.

In the default sssd.service file, the service 'Type' is 'notify' (It's the same in 20.04 and 22.04). However, the service is getting 'permission denied' errors when notifying systemd that the service is up. See attached.

If I use a service drop-in to change the service 'Type' to 'simple', the service starts immediately and works as intended.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: sssd 2.9.4-1.1ubuntu6
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CloudArchitecture: x86_64
CloudID: none
CloudName: none
CloudPlatform: none
CloudSubPlatform: config
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 09:20:02 2024
ProcEnviron:
 LANG=en_GB.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: sssd
UpgradeStatus: No upgrade log present (probably fresh install)

[James Paton-Smith (jamesps)]

I should add that this is a system built with TPM-backed FDE if that has any relevance. I haven't tested on a non-encrypted system.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andreas Hasenack (ahasenack)]

This is odd, as sssd has a good test suite[1] which exercises ldap integration, kerberos, and even smart card logins:

(...)
2183s autopkgtest [16:30:29]: @@@@@@@@@@@@@@@@@@@@ summary
2183s ldap-user-group-ldap-auth PASS
2183s ldap-user-group-krb5-auth PASS
2183s sssd-softhism2-certificates-tests.sh PASS
2183s sssd-smart-card-pam-auth-configs PASS

I've seen that kind of permission denied errors with systemd notifications in the past when the application was under apparmor confinement, but sssd doesn't have a default apparmor profile. In any case, do you see anything in the `dmesg -wT` output or even /var/log/syslog when you try to start sssd and get this error?

1. https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/s/sssd/20240421_163046_bc362@/log.gz

[James Paton-Smith (jamesps)]

Here is the dmesg output when trying to start sssd. I'll attach syslog as well from the same time period

[Andreas Hasenack (ahasenack)]

Did you install this fde/tpm setup using the ubuntu desktop noble installer? Or was hit some manual setup?

Can you also show the output of:

ps fauxwZ

If you don't want to disclose all that list, what we are looking for are the systemd processes (in particular, PID 1), and the sssd processes.

[Andreas Hasenack (ahasenack)]

Looks like cups is also affected:
2024-04-30T15:32:24.172187+01:00 ubu-o-8aa620b8b277 kernel: audit: type=1400 audit(1714487544.169:235): apparmor="DENIED" operation="sendmsg" class="file" profile="/usr/sbin/cupsd" name="/systemd/notify" pid=4835 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

The sssd process, however, was "ALLOWED", hinting that the apparmor profile is in complain mode:

[Tue Apr 30 15:32:05 2024] audit: type=1400 audit(1714487525.544:225): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/sssd" name="systemd/notify" pid=4822 comm="sssd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

Can you try disabling the apparmor profile for sssd? It would be a command like:

sudo aa-disable /usr/sbin/sssd

[Andreas Hasenack (ahasenack)]

> and the sssd processes.

... which of course you won't have, because it's failing to start (unless you apply your workaround).

[Andreas Hasenack (ahasenack)]

Ok, I was able to reproduce this in a VM setup (following https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2064096/comments/4). And if the apparmor profile is removed for sssd, even though it was in complain mode (not enforce), then sssd starts just fine.

To clarify, this is happening when installing Noble desktop with the TPM+FDE option. It doesn't look like it's an sssd bug. This is also happening with cups and rsyslog. Where exactly the problem is we don't know yet.