On (10/03/17 14:50), fidencio wrote:
URL: https://github.com/SSSD/sssd/pull/183 Title: #183: More socket-activation fixes
fidencio commented: """ @sgallah, @lslebodn
On Fri, Mar 10, 2017 at 2:22 PM, Stephen Gallagher <notifications@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()" call responders except sssd-nss and monitor.
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