On (09/01/17 10:43), Fabiano Fidêncio wrote: >On Mon, Jan 9, 2017 at 10:27 AM, Lukas Slebodnik <lsleb...@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@/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. :-\ > I let decide others what is more reasonable and simpler.
LS _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
