The SSSD team is proud to announce the release of the version 1.5.8
bugfix and enhancement release of the System Security Services Daemon.
This release fixes several bugs and is a recommended update for all
users of the 1.5.x series.
As always, it can be downloaded at https://fedorahosted.org/sssd
== Highlights ==
* Support for the LDAP paging control
* Support for multiple DNS servers for name resolution
* Fixes for several group membership bugs
* Fixes for rare crash bugs
== Detailed Changelog ==
Jakub Hrozek (2):
* Set c-ares to retry nameservers
* Only save members for successfully saved groups
Simo Sorce (1):
* clients: use poll instead of select
Stephen Gallagher (5):
* Make "password" the default for ldap_default_authtok_type
* simple provider: Don't treat primary GID lookup failures as fatal
* Enable paging support for LDAP
* IPA Provider: don't fail if user is not a member of any groups
* Add more detail to ldap_uri manpage entry
Sumit Bose (2):
* Return pam data to the renewal item if renewal fails
* Sanitize username during initgroups call
Kaushik found a code path where we didn't sanitize the user name. To
reproduce it try to authentication as an LDAP user with a user name like
'user\01'. It is important to have '\0' followed by other characters in
The attached patch should fix the issue. The related trac ticket is
This patch is related to https://fedorahosted.org/sssd/ticket/878
Although with how our code currently works, there is no way the
uninitialized variable could be returned to user, we might in future add
new calls that return arbitrary errno values. In that case the check for
value of ret would not be sufficient.
The attached patch adds a separate fail: label used for failure exits
from the function.
with this email I would like to start some discussion and collect ideas
and use-cases about a new concept for sssd, namely sub-domains.
Currently in sssd a domain is like a single namespace which has to be
defined in sssd.conf and only users from explicitly known domains are
supported. E.g. if you have only domains A and B configured then every
request for a user from domain C is already rejected by the nss
But what if, e.g. the server for domain A is an Active Directory server
and the AD admin decides to create a trust to a new Active Directory
domain C? Since the server trust domain C every member of his domain
should trust members from domain C as well. Currently we have to add
domain C to sssd.conf to allow users from domain C to access services on
the client running sssd.
But this will get cumbersome if domain C already trusts other domains
like D and E and if the admin of domain E decides later on to create a
new trust do domain F. Wouldn't is be nice if user and groups from these
domains can be accessed by sssd without being configured explicitly?
Currently there is work in progress to solve
https://fedorahosted.org/sssd/ticket/364 . A winbind based provider
would be able to enumerate and authenticate users and groups from
trusted AD domains, but as mentioned earlier a request for a user from
domain F (user@F) will be rejected by the nss responder, because it is
not configured explicitly and so sssd does not know anything about
So it would be nice if sssd can handle the domains C, D, E and F as
sub-domains of the configured domain A without an explicit
To solve this we might need to implement a new method to the providers
to return the names of the domains the backend can handle. Then the
frontends (pam and nss) can query the backends for the list of supported
domains and can decided which backend shall handle the request.
If you have different ideas about how to handle sub-domains or can think
of different use-cases other then the Active Directory one mentioned
above, please let me know. I would like to collect the ideas and write
up a design for sub-domains based on your input.
Thank you very much for your help.
there are a couple of places where we set _GNU_SOURCE in the source
files to enable glibc specific extensions. If by chance
'-D_GNU_SOURCE=1' is set on the gcc command line, e.g. by using the
CFLAGS from a pkg-config output (yes, there are examples :-), we get
'"_GNU_SOURCE" redefined' message during compilation. With the attached
patch _GNU_SOURCE is only defined in the sources if not already set.
An alternative fix would be to remove all defines of _GNU_SOURCE from
the source code and add AC_USE_SYSTEM_EXTENSIONS/AC_GNU_SOURCE to
configure.ac . I'm not sure if there is a recommended way how to handle
_GNU_SOURCE and friends.
Patch 0001: Stop building a fake interface version into the backend
plugins. This is not the correct way to create a plugin module with
libtool. Since the interface and the plugins are built at the same time,
the correct method is to produce an unversioned .so.
Patch 0002: Build the sssd utility sources as an internal libtool helper
library. This should speed the build up quite a bit, as what we had been
doing is rebuilding all of the common sources for each binary and
library. We will now build them once as a helper library that is
statically linked into those binaries that require them.
There is one caveat with this: we now have to explicitly link this
helper library to the plugins, instead of consuming them from the
sssd_be binary. This is because there is no way to export the functions
through sssd_be from a helper library (that I have been able to find).
They stopped being visible to the plugins.
I'm debating whether we should be statically linking all of this common
code at all, or whether the libsss_util.la should just become a shared
library in its own right. For the moment I've kept it as-is, but as of
this patch, it's trivial to change over to a shared library. Comments
Please test patch 0002 very carefully. I tried most of the common
use-cases I could think of, but I'd prefer if it be tested in a few