On (20/11/19 11:57), Lawrence Kearney wrote:
Lukas et al.,
Thank you for the suggestion. I'll test that as soon as convenient. I'm
currently attending SC19 so spinning up labs is something best managed in
the mornings with coffee :-) .
Curiously I did have to change the ownership of the socket, and a few
service, unit files to sssd:root to get them to start. I would like to test
the daemon to running as an unprivileged user as much as possible. I did
not consider digging into the files themselves to check configured runtime
users, I should've.
Using "hybrid" sssd:root is not a good idea.
You should either remove sssd user/group from service files
or run sssd as completely unprivileged user.
As to your question I currently have no real use case for the socket
responders other than their potential for system level optimisation in
large enterprise deployments and kicking the tyres on the SSSD feature set
to both experiment with it and document the assessment, results, and
configuration nuances and requirements.
And I an exactly interested in that real use-case :-)
Could you share a little bit more even thought you did not test it?
Because there might be other solution to the problem you would like to solve.