A couple of cosmetic changes related to IFP:

[alexey-tikhonov]

• warn loudly in case of dbus service policy misconfiguration - this might be common pitfall during transition toward non-privileged sssd
• remove excessive "Exec=" from dbus service file in case SSSD is built with system support (it had a wrong value anyway, imo)

[alexey-tikhonov]

* remove excessive "Exec=" from dbus service file in case SSSD is built with system support (it had a wrong value anyway, imo)

Well... it works, but https://dbus.freedesktop.org/doc/dbus-specification.html says:

Service description files *must* contain a D-BUS Service group with at least the keys Name and *Exec*. 
Additionally, service description files for the well-known system bus on Unix must contain a User key

I think this is just outdated wording, pre-"SystemdService" key was introduced, but formally it says so.

Still I'm not sure what should be a value of "Exec=".
If intention is to handle "monitor" activated case, then it should be 'sss_signal'.
Or, alternatively, sssd_ifp should exit on fail to acquire bus name, and to rely on restart instead of re-connection (by dbus-daemon either directly via "Exec=" or indirectly via "SystemdService"). Btw, sss_signal could be removed in this case.

@pbrezina, what would you say?

[alexey-tikhonov]

To summarize, there are 3 different ways how 'sssd_ifp' can be started:
(1) automatically by 'monitor' via sssd.conf::services
(2) by systemd either via 'systemct' manually or via dbus-socket activation ("SystemdService=")
(3) by dbus-broker via "Exec=" if systemd isn't available

"Exec=" option in dbus service description is formally mandatory and in case
(1) should be set to "sss_signal" according to intention behind 1a59af8
(2) isn't actually used, so doesn't matter what is its value (besides it might create confusion)
(3) should be set to "sssd_ifp" (maybe it was intention behind 9222a4f but it doesn't look correct as it actually changed "Exec=" for case (2) but not (3))

There is clearly a contradiction between (1) and (3)
I think we should give up supporting one of options in default packaging (and let users configure it manually if needed).

We can either disallow starting 'sssd_ifp' via 'monitor' (as this is more or less the case with 'sssd_kcm'), or stop keeping (3) in mind while maintaining config files.

[alexey-tikhonov]

Ok, I opted for

stop keeping (3) in mind while maintaining config files

and just added a dynamic comment that explains "Exec=" option for cases (1) and (2).

[justin-stephenson]

s/sss_sinal/sss_signal/

[alexey-tikhonov]

Fixed.

[justin-stephenson]

One minor typo, but besides that Ack LGTM.

[aplopez]

LGTM.

[alexey-tikhonov]

Pushed PR: #6868

• master
  • d91c944 - IFP: add a comment to 'org.freedesktop.sssd.infopipe.service' to avoid potential confusion
  • 9380c8e - SBUS: warn loudly if bus denies access