On Mon, Jan 9, 2017 at 10:27 AM, Lukas Slebodnik <lslebodn(a)redhat.com> wrote:
On (08/01/17 21:44), Fabiano Fidêncio wrote:
>People,
>
>Recently I've faced some issues when testing the socket-activation
>working running as sssd-user, which will force me to take a different
>path for a few things and I really would like to know your opinion on
>those things.
>
>So, currently, this is what the nss.service looks like:
>
>[Unit]
>Description=SSSD NSS Service responder
>Documentation=man:sssd.conf(5)
>After=sssd.service
>BindsTo=sssd.service
>
>[Install]
>Also=sssd-nss.socket
>
>[Service]
>ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath(a)/sssd_nss.log
>ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start
>Restart=on-failure
>User=@SSSD_USER@
>Group=@SSSD_USER@
>PermissionsStartOnly=true
>
>As you probably noticed, I've been using systemd's machinery to change
>the debug files' owner and to start the responder by the proper user
>(sssd or root). Well, it doesn't work that well as expected as systemd
>ends up calling initgroups(sssd, ...) in order to start any service
>using "sssd" user and this call is done _before_ starting the NSS
>responder, which will hang for the "default client timeout" (300s).
>
It is not just about initgroups(). I checked the source code and
it also calls getpwname get grname for User/GID !=0 and Group/GID !=0.
It is not a problem ATM but it would be problem after changing nsswitch
"passwd: files sss" -> "passwd: sss files"
Yes; we can remove this options from nss service file; but there
still will be a chown in ExecStartPre; which will cause problems
after changing nsswitch configuration. It would not be a problem
with "chown $uid:$gid" but these values are not constant.
Sorry, maybe I was not clear enough when writing the email.
My proposal is to have --sssd-user=@SSSD_USER@ passed as a command
line argument to the responder.
So, exactly as it's done nowadays, we would be able to own the debug
files and become the user without any issue (with the patches I've
described in the email).
And we need to change owner of the log file otherwise we would
not be able to start responder after upgrade from root user without
socket activation -> non-root user with socket activation.
Answered above.
We cannot translate sssd user to uid/gid at build time
because values would be different on build machine (chroot ...)
and on installed machine.
Answered above.
I think the only reasonable solution for non-root mode and nss responder
would be to provide drop-in file with uid/gid in /etc/systemd/system
I wrote the email giving another reasonable solution for non-root mode. :-\
The same as for logging to journald
/etc/systemd/system/sssd.service.d/journal.conf
We can replace values in rpm posinstall scriptlet and enable it by default.
Other distributions might do the same or they can rely on manual change.
That will be a downstream packager decision.
LS
_______________________________________________
sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
Best Regards,
--
Fabiano Fidêncio