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 <notifications(a)github.com> wrote:
On (10/03/17 05:50), fidencio wrote:
>@sgallah, @lslebodn
>
>On Fri, Mar 10, 2017 at 2:22 PM, Stephen Gallagher <
notifications(a)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_iao...
.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/183#issuecomment-285735941