Bug#994807: sssd-common: capabilities restrictions break the service

[Marc Dequènes]

Package: sssd-common
Version: 2.5.2-2
Severity: important


Quack,

This morning sssd got upgraded from 2.4.1-2 to 2.5.2-2 and I could not
log in as user. I use sssd-ldap + sssd-dbus + sssd-tools (the rest is
automatically installed).
I tried to downgrade but that did not solve anything, that was weird.

The service failed with:
● sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor
preset: enabled)
Active: activating (start) since Tue 2021-09-21 12:11:07 JST; 30ms
ago
Main PID: 3094 (sssd)
Tasks: 1 (limit: 38361)
Memory: 2.2M
CPU: 14ms
CGroup: /system.slice/sssd.service
└─3094 /usr/sbin/sssd -i --logger=files

Sep 21 12:11:07 Annael systemd[1]: Starting System Security Services
Daemon...
Sep 21 12:11:07 Annael sssd[3094]: Starting up
Sep 21 12:11:07 Annael sssd[3094]: dbus[3094]: arguments to
dbus_server_get_address() were incorrect, assertion "server != NULL"
failed in file ../../../dbus/dbus-server.c line 835.
Sep 21 12:11:07 Annael sssd[3094]: This is normally a bug in some
application using the D-Bus library.
Sep 21 12:11:07 Annael sssd[3094]: D-Bus not built with -rdynamic so
unable to print a backtrace

Then the daemon crashed because in src/sbus/server/sbus_server.c
sbus_server_socket_listen() only logs the problem without stopping:
Storage:
/var/lib/systemd/coredump/core.sssd.0.b78fd458dc7e43a29506481bb2d20de3.3094.1632193867000000.zst
Message: Process 3094 (sssd) of user 0 dumped core.

Stack trace of thread 3094:
#0 0x00007f3ba7170e71 __GI_raise (libc.so.6 + 0x3ce71)
#1 0x00007f3ba715a536 __GI_abort (libc.so.6 + 0x26536)
#2 0x00007f3ba6c25d62 n/a (libdbus-1.so.3 + 0xed62)
#3 0x00007f3ba6c48b60 _dbus_warn_check_failed
(libdbus-1.so.3 + 0x31b60)
#4 0x00007f3ba6c40592 dbus_server_get_address
(libdbus-1.so.3 + 0x29592)
#5 0x00007f3ba73214ba sbus_server_create
(libsss_sbus.so + 0x284ba)
#6 0x00007f3ba730e7b4
sbus_server_create_and_connect_send (libsss_sbus.so + 0x157b4)
#7 0x0000560ec6eada62 n/a (sssd + 0x5a62)
#8 0x00007f3ba715be4a __libc_start_main (libc.so.6 +
0x27e4a)
#9 0x0000560ec6eadbba n/a (sssd + 0x5bba)

Anyway, dbus was started and now that I found a workaround (see below) I
can say it works fine and that is not the problem.

I tried various things to no avail and decide to put aside my config and
purge/reinstall all *sss* packages. After putting back my config and
starting again I got:
# systemctl restart sssd

Broadcast message from systemd-journald@Annael (Tue 2021-09-21 17:12:14
JST):

sssd[11845]: Could not open file [/var/log/sssd/sssd.log]. Error:
[13][Permission denied]

Job for sssd.service failed because a fatal signal was delivered causing
the control process to dump core.
See "systemctl status sssd.service" and "journalctl -xe" for details.

And more precisely in the journal:
Sep 21 17:13:45 Annael sssd[11975]: Starting up
Sep 21 17:13:45 Annael sssd[11975]: dbus[11975]: arguments to
dbus_server_get_address() were incorrect, assertion "server != NULL"
failed in file ../../../dbus/dbus-server.c line 840.
Sep 21 17:13:45 Annael sssd[11975]: This is normally a bug in some
application using the D-Bus library.
Sep 21 17:13:45 Annael sssd[11975]: D-Bus not built with -rdynamic so
unable to print a backtrace

Sep 21 17:21:55 Annael systemd[1]: Starting System Security Services
Daemon...
Sep 21 17:21:55 Annael sssd[14233]: Could not open file
[/var/log/sssd/sssd.log]. Error: [13][Permission denied]
Sep 21 17:21:55 Annael sssd[14233]: Error opening log file, falling back
to stderr
Sep 21 17:21:55 Annael sssd[14233]: [sssd] [ldb] (0x0020): Unable to
open tdb '/var/lib/sss/db/config.ldb': Permission denied
Sep 21 17:21:55 Annael sssd[14233]: [sssd] [ldb] (0x0020): Failed to
connect to '/var/lib/sss/db/config.ldb' with backend 'tdb': Unable to
open tdb '/var/lib/sss/db/config.ldb': Permission denied
Sep 21 17:21:55 Annael sssd[14233]: [sssd] [confdb_init] (0x0010):
Unable to open config database [/var/lib/sss/db/config.ldb]
Sep 21 17:21:55 Annael sssd[14233]: [sssd] [confdb_setup] (0x0010): The
confdb initialization failed [5]: Input/output error
Sep 21 17:21:55 Annael sssd[14233]: [sssd] [load_configuration]
(0x0010): Unable to setup ConfDB [5]: Input/output error
Sep 21 17:21:55 Annael sssd[14233]: [sssd] [main] (0x0010): SSSD
couldn't load the configuration database.
Sep 21 17:21:55 Annael sssd[14233]: SSSD couldn't load the configuration
database [5]: Input/output error.
Sep 21 17:21:55 Annael systemd[1]: sssd.service: Main process exited,
code=exited, status=4/NOPERMISSION
Sep 21 17:21:55 Annael systemd[1]: sssd.service: Failed with result
'exit-code'.

After trying various solutions I found out that if I comment
CapabilityBoundingSet in the service file everything works fine again. I
purged and reinstalled all again to be sure this is the only change. I
tried adding extra capabilities but I could not find the correct set.

I honestly got confused by the permissions: /var/lib/sss has various
directories owned by the sssd user but the service is only run as root.

Tell me if you need more info.
Regards.
\_o<



-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sssd-common depends on:
ii adduser 3.118
ii libc-ares2 1.17.2-1
ii libc6 2.32-4
ii libdbus-1-3 1.13.18-2
ii libdhash1 0.6.1-2
ii libglib2.0-0 2.70.0-1
ii libgssapi-krb5-2 1.18.3-7
ii libini-config5 0.6.1-2
ii libkeyutils1 1.6.1-2
ii libkrb5-3 1.18.3-7
ii libldap-2.4-2 2.4.59+dfsg-1
ii libldb2 2:2.2.0-3.1
ii libnfsidmap2 0.25-6
ii libnl-3-200 3.4.0-1+b1
ii libnl-route-3-200 3.4.0-1+b1
ii libp11-kit0 0.24.0-2
ii libpam0g 1.4.0-10
ii libpcre2-8-0 10.36-2
ii libpopt0 1.18-3
ii libref-array1 0.6.1-2
ii libselinux1 3.1-3
ii libsemanage1 3.1-1+b2
ii libssl1.1 1.1.1l-1
ii libsss-certmap0 2.5.2-2
ii libsss-idmap0 2.5.2-2
ii libsss-nss-idmap0 2.5.2-2
ii libsystemd0 247.9-1
ii libtalloc2 2.3.1-2+b1
ii libtdb1 1.4.3-1+b1
ii libtevent0 0.10.2-1
ii python3 3.9.2-3
ii python3-sss 2.5.2-2

Versions of packages sssd-common recommends:
ii bind9-host 1:9.16.15-1
ii libnss-sss 2.5.2-2
pn libpam-sss <none>

Versions of packages sssd-common suggests:
ii apparmor 3.0.3-2
pn libsss-sudo <none>
ii sssd-tools 2.5.2-2

-- no debconf information


--
Marc Dequènes

[Timo Aaltonen]

Hi,

Thanks for the detailed bug report. Upstream added the capability
limitations to the service files in 2.5, and for the old ways we'd need
CAP_DAC_OVERRIDE so it would work with files owned by sssd user while
the daemon is running as root (or so I'm told anyway).

But since the 'run sssd as a non-privileged user' -feature is still not
used in Fedora either, best to make it run as root and change the file
permissions to match.

I've pushed a new version to salsa, could you build and test that in
your environment? The autopkgtest at least passes so the daemon should
work (and didn't on the current version, which I didn't notice, boo).

thanks!



--
t

[Marc Dequènes]

Quack,

On 2021-09-22 18:28, Timo Aaltonen wrote:

> But since the 'run sssd as a non-privileged user' -feature is still
> not used in Fedora either, best to make it run as root and change the
> file permissions to match.

I guess it's not ready yet and following Fedora seems the best thing to
do.

> I've pushed a new version to salsa, could you build and test that in
> your environment? The autopkgtest at least passes so the daemon should
> work (and didn't on the current version, which I didn't notice, boo).

I built it and restarted, no problem. I removed sbus-monitor, restarted,
and it was able to recreate it.
Thanks for the quick fix :-).

Regards.
\_o<

--
Marc Dequènes

[Timo Aaltonen]

On 22.9.2021 17.43, Marc Dequènes (duck) wrote:
> Quack,
>
> On 2021-09-22 18:28, Timo Aaltonen wrote:
>
>> But since the 'run sssd as a non-privileged user' -feature is still
>> not used in Fedora either, best to make it run as root and change the
>> file permissions to match.
>
> I guess it's not ready yet and following Fedora seems the best thing to do.

Yeah, I try to follow them when possible, but some changes do go
unnoticed still.

>> I've pushed a new version to salsa, could you build and test that in
>> your environment? The autopkgtest at least passes so the daemon should
>> work (and didn't on the current version, which I didn't notice, boo).
>
> I built it and restarted, no problem. I removed sbus-monitor, restarted,
> and it was able to recreate it.
> Thanks for the quick fix :-).

Excellent, I'll add some other fixes too and upload.


--
t