We will have some experimental features added in the near future and
this patch tries to help to identify them. One part is a new configure
option which enables all experimental features which check if the option
is set. The second is a small include file for man pages to indicate
that a certain feature is experimental.
"Release early, release often" is the motto of this version 1.5.11 of
the System Security Services Daemon.
A serious regression was discovered in SSSD 1.5.9 and 1.5.10 that
prevented the LDAP provider from being able to contact ldaps:// URIs.
SSSD 1.5.11 has been released to resolve this issue (along with a few
other, small bugfixes).
== Highlights ==
* Fix a serious regression that prevented SSSD from working with
* IPA Provider: Fix a bug with dynamic DNS that resulted in the wrong
IPv6 address being saved to the AAAA record.
== Detailed Changelog ==
Jakub Hrozek (2):
* ipa_dyndns: Use sockaddr_storage for storing IP addresses
* Fix unchecked return values of pam_add_response
Matthew Ife (1):
* Replace system() function with fork and execl call.
Stephen Gallagher (1):
* Bumping version to 1.5.11
Sumit Bose (1):
* Call ldap_install_tls() on ldaps connections
This patch add the possibility to exclude attributes when building requested
attribute list from a map. It also utilizes this new functionality by not
loading memberuid of parent groups during initgroups in rfc2307 schema.
I know this is not a massively important matter, but I was just
noticing the date discrepancies on the page that details your
The release page says that sssd-1.5.10 was released on Date:
Imagine my depression when I realized that 1.5.10 had been out for
an entire year and I haven't been using it!
Thanks, all contributors!
Martin A. Brown --- Renesys Corporation --- mabrown(a)renesys.com
On Wed, 2011-06-29 at 23:35 +0100, Matthew Ife wrote:
> Hi Stephen,
> I am working on the SSSD policy for local db management and hit across
> an alert that I believed should be fixed in code.
> The alert is because nscd.c called system() to request a flush command
> to nscd if it exists.
> This is a problem policy wise because this calls /bin/sh to execute the
> command which in turn forces policy to allow a much greater access to
> sssd to execute stuff that exists in /usr/bin and friends.
> In the patch attached I replaced the system() request with a fork/execl
> pair. This is much nicer in policy as I can change policy to call a
> specific transition into the nscd_t domain directly without giving
> access to sssd to the bin_t types in /usr/bin.
> Please check the patch. I'm not familiar with talloc (I dont really
> consider myself a C programmer of any merit) and my workaround to create
> a char** array to talloc memory might be a bit daft to do. If you can
> alter the code to something more elegant please feel free!
> On Mon, 2011-06-27 at 07:13 -0400, Stephen Gallagher wrote:
> > I happened to notice this email on the selinux list. This discussion
> > would probably be best served cross-posted to
> > sssd-devel(a)lists.fedorahosted.org, so we on the SSSD team can be
> > involved if there are any code changes/improvements we need to make in
> > order to further advance this proposal.
I took a look at the patch, and unfortunately it would need a fair
amount of rework to get it to function properly. However, it brings up
an interesting topic that I'd like to discuss with the SSSD list at
The main reason for the nscd flush is because, for a time, we were
attempting to allow the SSSD to operate alongside NSCD. These days,
however, we've acknowledged that the two caches really don't interact
well and we strongly advise that users disable user and group support in
nscd while using SSSD.
So I'd like to propose that, rather than fixing this code to work in the
way Matthew is suggesting, we remove it entirely, acknowledging that
nscd/sssd interaction is unlikely to ever be safe.
I'm using sssd-1.5.10 and noticed today that I was not able to connect to my ldap server with an ldaps uri.
If I change the uri it ldap://ldap.... everything works just fine. As far as I can see it is not an certificate issue.
connection attempt with ldaps://ldap...
slapd: conn=118207 fd=77 ACCEPT from IP=192.168.1.1:8837 (IP=0.0.0.0:636)
slapd: conn=118207 fd=77 closed (TLS negotiation failure)
connection attempt with ldap://ldap...
slapd: conn=118259 fd=72 ACCEPT from IP=192.168.1.1:47669 (IP=0.0.0.0:389)
slapd: conn=118259 op=0 EXT oid=184.108.40.206.4.1.1466.20037
slapd: conn=118259 op=0 STARTTLS
slapd: conn=118259 op=0 RESULT oid= err=0 text=
slapd: conn=118259 fd=72 TLS established tls_ssf=256 ssf=256
Am I missing something?
Thanks in advance,
this series of patches adds support to receive a windows PAC via GSSAPI
and to create a user based on the data in the PAC. This is useful
because in an environment with lots of trust relationships between AD
server it might be quite time consuming to find out about all the group
memberships of a domain user by querying the domain controllers. But the
PAC contains all information about group memberships of the
The general idea is to add the user, if it doesn't exist in the cache,
to the cache of the corresponding domain (see thread about sub-domains,
currently this patch add the user to the local domain for simplicity)
and to add all group memberships (currently not implemented). If one of
the groups cannot be found in the cache a dummy entry with all data
needed to resolve this group quickly is added to the cache.
Currently there are a couple of loose end, e.g.
- groups and group memberships are not handled
- PAC is not validated
- missing sub-domains
- no real SID to uid/gid mapping
etc, but I like to start the discussion about the code and the general
direction as soon as possible. Currently sssd with these patches can
only be build on rawhide, because of the dependencies to the samba4
Patch 0007 contains a little example that demonstrates that the pac
responder can also be used to add user and groups based on other input,
e.g. it can be used as a backend for the sss_* utilities. This would
allow a much better control about which user is allowed to do what kind
of operation. Currently only the root user can add and modify user and
group entries with the sss_* tools.
I have used 'pac' as a part of names here because this was the original
target, but I would be happy to change it to a more generic keyword if
anyone has a good suggestion.
Hot on the heels of SSSD 1.5.9 comes version 1.5.10 of the System
Security Services Daemon to correct a regression in 1.5.9 discovered
just after 1.5.9 got out the door.
As always, it can be downloaded from
== Highlights ==
* Fixed a regression introduced in 1.5.9 that could result in blocking
calls to LDAP
== Detailed Changelog ==
Stephen Gallagher (2):
* Bumping version to 1.5.10
* Do not attempt to close() a file descriptor < 0
Sumit Bose (1):
* Do not access state after tevent_req_done() is called.