On (09/01/17 10:43), Fabiano Fidêncio wrote:
On Mon, Jan 9, 2017 at 10:27 AM, Lukas Slebodnik
> On (08/01/17 21:44), Fabiano Fidêncio wrote:
>>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
>>So, currently, this is what the nss.service looks like:
>>Description=SSSD NSS Service responder
>>ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath(a)/sssd_nss.log
>>ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start
>>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.
> We cannot translate sssd user to uid/gid at build time
> because values would be different on build machine (chroot ...)
> and on installed machine.
> 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. :-\
I let decide others what is more reasonable and simpler.