URL:
https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
jhrozek commented:
"""
Hi,
I read the patches, so far I didn't do a whole lot of testing, so maybe some questions
here are invalid, but nonetheless, here is my take on the patchset:
1. currently the patches don't work well if sssd is running with `user=root` because
then the confdb is owned by root and the responders, which always start as the sssd user
cannot read it. I think we could solve this particular problem by owning the confdb as
sssd/sssd from the start -- I don't think there would be any information leak because
the confdb is then only readable to sssd and root and the sssd user's shell is
hopefully` /sbin/nologin`. However, just the presence of the sssd user is currently
conditional (`--with-sssd-user` still defaults to root). I wonder if it was the easiest to
conditionalize the unit and socket files and expand the sssd user instead of hardcoding
sssd there?
1. There seems to be some issue with PAM socket ownership because I can't authenticate
with socket-activated PAM responder:
`Dec 12 11:36:11 client.ipa.test su[29517]: pam_sss(su-l:auth): Request to sssd failed.
Public socket has wrong ownership or permissions.`
1. Would it make any sense to own the sockets by the sssd user as well? Currently it seems
the sockets are owned by the sssd user for services started by monitor if they are running
un-privileged but as root for systemd-activated services. Because the
1. There were some SELinux denials on my test VM, but granted, I run F-24 there. We need
to make sure that no SELinux AVC denials are present in Fedora later.
1. In the upstream reference specfile, should we use the systemd macros as we do for
services so that all sockets are enabled and started?
1. The documentation should be improved a bit. At least we should say that the services
line is only optional on systemd platforms. I think we should also add an example that
lists how to disable a socket if the admin wants to totally disable some service.
1. I'm wondering if the restart on-failure is correct. I think it is, but I would like
to discuss it a bit. Currently the restart is done on any return code other than 0. The
only issue I see is that the restart is retried several times if the service fails to
start up, but in general I think it's much safer than trying to be too smart and only
restart with on-abnormal. Do you agree?
That's all for now, I will continue reading the patches and testing them later.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/94#issuecomment-266407528