[Pkg-sssd-devel] Bug#886483: sssd gets confused by existing config file

[Juha Jäykkä]

Package: sssd
Version: 1.16.0-3
Severity: minor

Dear Maintainer,

There is a regression in 1.16.0-2 and -3, rendering existing sssd configurations
unable to authenticate users. This happens if the old config file has 

services = nss, pam

in it. This used to be "the right way" of doing things but now with socket activated
nss and pam services sssd gets confused and its pam service no longer works. Removing
said line fixes it (hence "Severity: minor") but this is highly confusign to the admin
as the service seems to be up and running.

The clue is in the log:

Jan 06 14:50:47 rigel sssd_check_socket_activated_responders[8175]: (Sat Jan  6 14:50:47:876645 2018) [sssd] [main] (0x0010): Misconfiguration found for the pam responder.
Jan 06 14:50:47 rigel sssd_check_socket_activated_responders[8175]: The pam responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf.
Jan 06 14:50:47 rigel sssd_check_socket_activated_responders[8175]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the pam's socket by calling:
Jan 06 14:50:47 rigel sssd_check_socket_activated_responders[8175]: "systemctl disable sssd-pam.socket"
Jan 06 14:50:47 rigel systemd[1]: sssd-pam-priv.socket: Control process exited, code=exited status=17
Jan 06 14:50:47 rigel systemd[1]: sssd-pam-priv.socket: Failed with result 'exit-code'.
Jan 06 14:50:47 rigel systemd[1]: Failed to listen on SSSD PAM Service responder private socket.
Jan 06 14:50:47 rigel systemd[1]: Dependency failed for SSSD PAM Service responder socket.
Jan 06 14:50:47 rigel systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result 'dependency'.
Jan 06 14:50:47 rigel systemd[1]: Listening on SSSD NSS Service responder socket.

Note how the log says "please consider" instead of "this is an error, this will not work" and
later shows a failure.

>From the first "please consider" message I would presume sssd is supposed to gracefully
recover. The service seems to start when needed and responds to some queries but always ends
auth process with

[sssd[pam]] [pam_dp_process_reply] (0x0010): Reply error.

And this means auth failure for pam of course.

Cheers,
Juha

P.S. This may be "works as intended" but considering it took me quite a while to figure
out why my existing, working configuration got broken and google came up with no help at all,
I would think at least getting this report onto google results would be helpful to some people.

Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sssd depends on:
ii  python3-sss  1.16.0-3
ii  sssd-ad      1.16.0-3
ii  sssd-common  1.16.0-3
ii  sssd-ipa     1.16.0-3
ii  sssd-krb5    1.16.0-3
ii  sssd-ldap    1.16.0-3
ii  sssd-proxy   1.16.0-3

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information