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.

As to your question I currently have no real use case for the socket based
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.

I often share these results in attempts to help others deploying the daemon
and advocate for its use. Similar to this community :-) .


Thank you again and I'll test asap and report what I find,


-- lawrence

On Wed, Nov 20, 2019 at 11:16 AM Lukas Slebodnik <lsleb...@redhat.com>
wrote:

> On (15/11/19 05:23), Lawrence Kearney wrote:
> >SSSD team,
> >Just checking in on this post. Any thoughts why the socket based
> responders
> >would be crashing? Is there any additional info I could provide that would
> >be useful?
> >
> >Thank you as always!
> >
>
> sssd on rhel7 has hardcoded unprivileged user "sssd" for responders.
> And mixing privileged sssd and unprivileged users is not a good idea.
>
> sh# rpm -q sssd-common
> sssd-common-1.16.4-21.el7_7.1.x86_64
>
> sh# systemctl cat sssd-pam.service
> # /usr/lib/systemd/system/sssd-pam.service
> [Unit]
> Description=SSSD PAM Service responder
> Documentation=man:sssd.conf(5)
> After=sssd.service
> BindsTo=sssd.service
> RefuseManualStart=true
>
> [Install]
> Also=sssd-pam.socket sssd-pam-priv.socket
>
> [Service]
> Environment=DEBUG_LOGGER=--logger=files
> EnvironmentFile=-/etc/sysconfig/sssd
> ExecStartPre=-/bin/chown sssd:sssd /var/log/sssd/sssd_pam.log
>                          ^^^^^^^^^
>                           here
> ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated
> Restart=on-failure
> User=sssd
> Group=sssd
>      ^^^^^
>     and here
> PermissionsStartOnly=true
>
>
>
> It works well when sssd is running fully in unprivileged mode.
> "user = sssd" in "sssd" section of sssd.conf
>
> Other option would be to override service files for responder in
> /etc/systmd/system
>
> But I would like to ask why do you want to use socket activated responders
> on
> rhel7?
>
> LS
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

Reply via email to