Bug 988068

I don't think, that it is a sssd bug.

I reproduced it successfully with nss-pam-ldapd

Steps to Reproduce:
1. Install F19
2. Install nss-pam-ldapd, but service nslcd must be inactive
3. Configure nss to use nss-pam-ldap
   --file /etc/nsswitch have to contain line "passwd:     files ldap"
4. Compile short test program (from bug description)
5. Run it with a non-existing user:  ./t unknown-user

Results:
# ./t unknown-user
<unknown-user> err: <2>

Additional info:
Removing the ldap from nsswitch.conf results in your expected behaviour

According to libc(nss) manual documentation:
http://www.gnu.org/software/libc/manual/html_node/NSS-Modules-Interface.html

While the user-level function returns a pointer to the result the reentrant function return an enum nss_status value: 
NSS_STATUS_TRYAGAIN (numeric value -2)
NSS_STATUS_UNAVAIL (numeric value -1)
NSS_STATUS_NOTFOUND (numeric value 0)
NSS_STATUS_SUCCESS (numeric value 1)

In case the interface function has to return an error it is important that the correct error code is stored in *errnop. Some return status value have only one associated error code, others have more.

NSS_STATUS_UNAVAIL 	ENOENT 	A necessary input file cannot be found. 

In your case, sssd (_nss_sss_getpwnam_r) returned NSS_STATUS_UNAVAIL and
*errnop was set to ENOENT. ENOENT is defined as number "2". And number 2 is  returned from getpwnam_r in your example code.
The sssd behaves exactly as is described in the NSS-Modules-Interface documentation.

Possible solutions:
* NSS_STATUS_UNAVAIL should be handled in nss code
* manual pages of getpwnam_r should be updated

Seems like an glibc issue. I'm adding the glibc maintainer to CC list.

To be clear, my main issue is that the default F19 configuration breaks postfix.

Whether there's an actual bug in ssd/postfix/glibc, or if it's simple a matter of needing to remove or properly configure sssd in the default install, I'll leave to you to decide.

(In reply to Jochen De Smet from comment #4)
> To be clear, my main issue is that the default F19 configuration breaks
> postfix.

Understood.

> Whether there's an actual bug in ssd/postfix/glibc, or if it's simple a
> matter of needing to remove or properly configure sssd in the default
> install, I'll leave to you to decide.

you can certainly remove sss locally to work around the issue however this bug seem primarily a glibc inconsistency issue and to a lesser degree a postifx issue in the sense that it is being a little too strict.

This is what the man page says about retun errors:

RETURN VALUE
       The  getpwnam()  and  getpwuid() functions return a pointer to a passwd
       structure, or NULL if the matching entry  is  not  found  or  an  error
       occurs.   If an error occurs, errno is set appropriately.  If one wants
       to check errno after the call, it should be  set  to  zero  before  the
       call.
[..]
       On  success, getpwnam_r() and getpwuid_r() return zero, and set *result
       to pwd.  If no matching password  record  was  found,  these  functions
       return  0 and store NULL in *result.  In case of error, an error number
       is returned, and NULL is stored in *result.

now, for getpwname_r() it is true that the doc says 0 is returned if the user is not found, and this is where I think glibc's bug is as it is not respecting it when sss returns NSS_STATUS_UNAVAIL ENOENT
however postfix could also be a little bit more leninet and treate 0 and ENOENT the same as this is also in the manpage:

ERRORS
       0 or ENOENT or ESRCH or EBADF or EPERM or ...
              The given name or uid was not found.

I've read and re-read this issue a couple of times now and I come up with the same answer each time: this is a problem with the nss module for sss.

If you are the last lookup in a list of chained lookups and you return NSS_STATUS_UNAVAIL / ENOENT, that error will be propagated to the caller.

The error might have been hidden if you had a long list of lookups. The interface provides no way to inspect the failures of the lookups in the middle of the list. Thus if sss is in the middle of a list of lookups with the last lookup returning NSS_STATUS_NOTFOUND / ENOENT, then no error is returned.

There are many ways to resolve this problem, but somone needs to make a choice amongst them. I see no problem with glibc's behaviour. If you do, please explain why you think there is a problem and what is inconsistent about it.

I think that it is correct for the sss nss modules to return NSS_STATUS_UNAVAIL / ENOENT since that is exactly the problem. The sssd daemon is not running and the service is unavailable and that is a helpful diagnostic.

Comments?

I'm going to take this issue upstream to get a policy decision made and the documentation updated to clarify the exact situation we are facing here. Once we have a policy decision we can file specific bugs to fix issues.

In the meantime the glibc team is going to look at:

* Can we make glibc more conservative in fedora and not return an error for service failures. The API would instead return no result and no error. Errors will only be returned for critical internal failures.

I suggest others look at:

* What would it take to work around this in the nss_sss module e.g. do the wrong thing for the right reasons and don't return NSS_STATUS_UNAVAIL / ENOENT.

* Have a default config for sssd such that the service can be started right away.

Both of these solutions would be temporary until we can fix glibc.

I don't have an ETA for fixing this as we have quite a bit of other work, but I'll keep this issue updated.

Created attachment 788567 [details]
SSS client hacky workaround

I'm not necessarily condoning this approach, but if we *do* decide to hack together a workaround in nss_sss.so.2, the attached patch should cover it.

After log discussion the workaround in sssd was merged in sssd upstream.
https://fedorahosted.org/sssd/ticket/2439.

Therefore reassigning to sssd

There is a question whether we want patch in fedora 19 or ticket should be moved to fedora 20.

Fedora 19 will be out of life in a month.

Fedora 19 is EOL now.

But I think it still makes sense to track that this issue was resolved in sssd upstream.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2439

sssd-1.12.3-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/sssd-1.12.3-3.fc21

Package sssd-1.12.3-3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.12.3-3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-0900/sssd-1.12.3-3.fc21
then log in and leave karma (feedback).

sssd-1.12.3-4.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/sssd-1.12.3-4.fc21

sssd-1.12.3-4.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.