[SSSD] [PATCH] sss_client: Return a different error when sssd is not running

Lukas Slebodnik lslebodn at redhat.com
Thu Nov 13 10:17:15 UTC 2014


On (13/11/14 10:44), Jakub Hrozek wrote:
>On Wed, Nov 12, 2014 at 08:04:46PM -0500, Simo Sorce wrote:
>> On Wed, 12 Nov 2014 16:36:00 +0100
>> Lukas Slebodnik <lslebodn at redhat.com> wrote:
>> 
>> > On (12/11/14 10:00), Simo Sorce wrote:
>> > >I would create a helper function to be called on return that
>> > >transforms the error accordingly. This will allow to write the code
>> > >_and_ the comment once.
>> > >
>> > In this case, Stephan's patch is better
>> > https://bugzilla.redhat.com/attachment.cgi?id=788567
>> 
>> Yes, this is a valid alternative.
>> 
>> > >The comment should be changed to something like this in either case:
>> > >/* When sssd is stopped return a safe error code as if sss was not
>> > >configured at all in nsswitch. This prevents bogus errors from
>> > >causing issues in applications, before sssd starts or if it fails to
>> > >respond. */
>> > >
>> > >No need to mention that sss is by default in nsswitch, as it is not
>> > >in all distributions and it really is inconsequential, the same
>> > >behaviour change hleps when sss is not the default but is has been
>> > >manually added and sssd is stopped or not started yet (for example
>> > >during boot).
>> > nss-pam-ldapd has the same behaviour in the same situation.
>> > Will we patch it as well? It's very likely we won't.
>> 
>> Sorry, I do not see how that matters :)
>> 
>> > The biggest problem is that sss is by default in nsswitch on
>> > fedora/rhel>=7 due to glibc caching and problem with GNOME,
>> > a) sssd-client is installed by default on this platforms.
>> > b) sssd need't be configured by default and in most cases won't be
>> >     => sssd cannot run
>> > c) glibc developers don't want to adjust the error return code in
>> > glibc
>> > 
>> > As a result of this, we need to patch sssd.
>> > I would say we should patch sssd just in downstream and
>> > Stephan's patch works well. I tested it.
>> 
>> Ok, then let's go with Stephen's patch.
>> 
>> Simo.
>> 
>
>I don't personally mind whether we use Lukas' or Stephen's patch but I
>would /strongly/ prefer the patch to be pushed upstream.
>
I don't understant why we should push patch to upstream.
glibc maintainer confirmed that sssd behaves corectly:
"In all honesty, SSSD is *behaving* correctly. It returns:
status==NSS_STATUS_UNAVAIL, and errno==ENOENT, to indicate "A necessary input
file cannot be found."[1] I can only assume this is because it is true, the
daemon is not running and the return status as indicated implies that. Such an
error will be propagated up to the client, getgrent in this case, as a NULL
return with errno set to ENOENT."
(nss-pam-ldapd do the same with stopped nslcd)

The problem is that behaviour is unacceptable with having sss in the
nsswitch.conf by default (rhel>=7, fedora). I checked glibc upstream and
other distributions (debian, ubuntu, opensuse) and they don't have sss
in /etc/nsswitch.conf by default.

The patch in upstream can hide problems with stopped sssd. Some user can rely
on such behaviuour.

Why we should patch sssd in upstream due to some downstream patch in different
project?

LS



More information about the sssd-devel mailing list