URL: https://github.com/SSSD/sssd/pull/183 Title: #183: More socket-activation fixes
fidencio commented: """ On Fri, Mar 10, 2017 at 5:54 PM, lslebodn <notificati...@github.com> wrote: > On (10/03/17 05:50), fidencio wrote: > >@sgallah, @lslebodn > > > >On Fri, Mar 10, 2017 at 2:22 PM, Stephen Gallagher < > notificati...@github.com > >> wrote: > > > >> @lslebodn <https://github.com/lslebodn> > >> > >> @sgallagher <https://github.com/sgallagher> The purpose of calling > chown > >> in ExecStartPre is to allow starting responders as non-privileged from > >> beginning. Systemd drops permissions before exec. > >> > >> Yeah, I get that. And I told @fidencio <https://github.com/fidencio> on > >> IRC that we can live with the TOCTOU for the time being and figure out a > >> better option later. That said, we cannot use /usr/bin/chown for this, > >> because it unconditionally calls getpwnam()/getpwuid() in its execution, > >> which causes a problem when socket-activating. I suggested that we might > >> want to just create a reduced-functionality /usr/libexec/sssd/sss_chown > >> that calls only the low-level system function. > >> > > > >Well, considering we write our own sss_chown binary ... as we still don't > >have a static uid for the sssd user we would end up calling > >getpwnam()/getpwuid() for the unprivileged user. > > > we can call "getpwnam()/getpwuid()" in responders except > sssd-nss (and monitor). > We can, for sure. However, as far as I understand, @sgallagh would like to avoid SSSD having a circular dependency. > > In monitor we should set/unset env variable `_SSS_LOOPS` > > >In other others, it would solve the situation but only for the NSS > >responder. > > > Is there any problem to start other responders after sssd-nss? > > >What I'm proposing is to take a step back and do *not* support > unprivileged > >users for socket-activated services for now. Get the socket-activation > >working without cycle dependency on SSSD and avoid the TUCTOU issue. > > > >Once we have the static uid for the sssd user on Fedora then I can start > >bugging Debian/Ubuntu/openSUSE/SUSE maintainers in order to provide the > >same and we get back to supporting the unprivileged user for > >socket-activated services. > > > static uid/gid is not a solution; it's just a workaround. > > LS > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/SSSD/sssd/pull/183#issuecomment-285722632>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAG4ekDwZez-izo2Lix_iao2kIP46GYMks5rkYBcgaJpZM4MVyT_> > . > """ See the full comment at https://github.com/SSSD/sssd/pull/183#issuecomment-285735941
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
