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 <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.

In other others, it would solve the situation but only for the NSS
responder.

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.

That's my suggestion ... but I'd go with whatever you guys agree on ...

Best Regards,
--
Fabiano FidĂȘncio

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/183#issuecomment-285673416
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to