[Pkg-sssd-devel] Bug#994807: Bug#994807: sssd-common: capabilities restrictions break the service
Timo Aaltonen
tjaalton at debian.org
Wed Sep 22 10:28:17 BST 2021
On 21.9.2021 11.43, Marc Dequènes (duck) wrote:
> 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 at 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
>
>
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
More information about the Pkg-sssd-devel
mailing list