The purpose of registration is to identify connection by name. We already do it by natural d-bus way -- with naming the connection directly with d-bus name. So it is not strictly needed and I would like to remove it in the future also from provider.

I do not remember if I missed this on purpose or by mistake, but I do not think it needs to be changed. I let others decide.

The purpose of registration is to identify connection by name. ... I would like to remove it in the future also from provider

1) Is there any explicit way to make client to connect to sbus server (Monitor) without calling any methods (like Register)?
2) On server side: is it possible to "notice" incoming connection if it doesn't call any sbus method? I do not see any callbacks currently (but may be it is trivial to add, I don't know).

But from my point of view this idea definitely have a sense.
Currently clients calls register methods before entering main event loop. If client is stuck during initialization registration is never completed. Making initialization process simpler would be beneficial.

Ad 1) Yes, just connecting to the sbus server is sufficient. Method Register is really only about identifying the connection which is no longer strictly required as now the connection has its own name (like sssd.sudo, sssd.ifp, ...). Previously, this name was not available so you had to call this Register method to name the connection.

Ad 2) Yes and we do it for example in data provider. See dp_init_done and sbus_server_set_on_connection.

Ad 1) Sorry my question was not clear enough.
What I meant to ask: how to make a connection from client side (without calling method)?

Ad 2) So providers currently have both registration procedure and corresponding timeout.

Ad 1) See sbus_connect_private
Ad 2) Yes.

Do you want to add the timeout to monitor or should we close this issue?

Issue is clear: Monitor can be "attacked" this way (open huge amount of connections that does not perform even basic dbus handshake => out of mem).

But addition of timeout wouldn't remedy situation fully.
For example, if I understand correctly, Monitor doesn't check for "double registration" (of the same service) leaking memory in this case.

I can't judge if this is something important to address or may be ignored.

The socket can be accessed only by root:

srw-------. 1 root     root      0 Apr  1 12:09 sbus-monitor

If an attacker can talk to this socket, there is much bigger security concern then talking to SSSD. This was never about security, it was only about identifying the services. Therefore I am closing this. Feel free to reopen if you feel otherwise.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4953

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.