# SSSD 2.10.0-beta2

The SSSD team is announcing the release of version 2.10.0 of the
System Security Services Daemon. The tarball can be downloaded from:
     https://github.com/SSSD/sssd/releases/tag/2.10.0

See the full release notes at:
     https://sssd.io/release-notes/sssd-2.10.0.html

RPM packages will be made available for Fedora shortly.

## Feedback

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
     https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
     https://lists.fedorahosted.org/mailman/listinfo/sssd-users

# SSSD 2.10.0 Release Notes

## Highlights

### General information

* **IMPORTANT note for downstream maintainers!**

  This release features significant improvements of "running with less
  privileges (under   unprivileged service user)" feature. There is still a
  `./configure` option `--with-sssd-user=` available that allows downstream
package maintainers to choose if support of non-root service user should be built. In case such support is built, a preferred way to configure service
  user is simply by starting SSSD under this user; for example, using
`User=/Group=` options of systemd sssd.service file. Upstream defaults are
  to build `--with-sssd-user=sssd` and to install systemd service with
  `User=/Group=sssd`. In this case, only several helper processes -
  `ldap_child`, `krb5_child` and `selinux_child` - are executed with
  elevated capabilities (that are now granted using fine grained file
capabilities instead of SUID bit). All other SSSD components run without any capabilities. In this scenario it's still possible to re-configure SSSD to run
  under `root` (if needed for some reason): besides changing `User/Group=`
  options, some other tweaks of systemd service files are required.

A legacy method to configure a service user - sssd.conf `user` option - is now deprecated and its support isn’t built by default. It can be enabled using
  `--with-conf-service-user-support` `./configure` option if needed (for
  example, due to backward compatibility requirements of stable releases).

  Further, no matter if SSSD is built `--with-sssd-user=sssd` or
`--with-sssd-user=root`, when it's configured to run under `root` (in both
  cases) it still runs without capabilities, the same way as when it's
  configured to run under `sssd` user. The only difference is from the DAC
  perspective.

  Important note: owner of `/etc/sssd/sssd.conf` file (and snippets) should
  match the user configured to start SSSD service. Upstream spec file and
  service files change ownership of existing `sssd.conf` to sssd during
package installation and at runtime for seamless upgrades / transition period
  only.

  Additionally, this release fixes a large number of issues with "socket
activation of responders" feature, making it operable out-of-the-box when the
  package is built `--with-sssd-user=sssd`. Please take a note, that user
configured to run main sssd.service and socket activated responders (if used) should match (i.e. if sssd.service is re-configured from upstream defaults to
  `root` then responders services also should be re-configured).

Downstream package maintainers are advised to carefully inspect changes in
  `contrib/sssd.spec.in`, `src/sysv/systemd/*` and `./configure` options
  that this release brings!

* sssctl `cache-upgrade` command was removed. SSSD performs automatic upgrades
  at startup when needed.

* Support of `enumeration` feature (i.e. ability to list all users/groups
  using `getent passwd/group` without argument) for AD/IPA providers is
deprecated and might be removed in further releases. Those who are interested
  to keep using it awhile should configure its build explicitly using
  `--with-extended-enumeration-support` ./configure option.

* A number of minor glitches of `sssd-2.10.0-beta1` around building and
  packaging were fixed.

### New features

* The new tool `sss_ssh_knownhosts` can be used with ssh's
`KnownHostsCommand` configuration option to retrieve the host's public keys
  from a remote server (FreeIPA, LDAP, etc.). This new tool, which is more
reliable, replaces `sss_ssh_knownhostsproxy`. The latter is no longer built
  by default, but its build can be forced with the `./configure` option
  `--with-ssh-known-hosts-proxy`.

### Packaging changes

* Building SSSD now unconditionally requires availability of `ucred`/
  `SO_PEERCRED` to enforce certain security checks at runtime (see `man 7
  unix` for details).

* SSSD now requires `libini` not older than v1.3

* Explicit `--with-semanage` ./configure switch was removed, going forward
  `--with-selinux` includes this.

* `sssd_pam` binary lost public `rx` bits and got `cap_dac_read_search=p`
  file capability to be able to use GSSAPI

* Support of OpenSSL older than 1.0.1 was dropped

* Support of `--without-infopipe` `./configure` option was dropped. Feature
is long time out of experimental state. Since building it doesn't require any additional dependencies, there is not much sense to keep option available. Those who not interested in feature can skip installing sssd-ifp sub-package.

### Configuration changes

* Default `ldap_id_use_start_tls` value changed from `false` to `true` for
  improved security.

* Added a `ldap_use_ppolicy` option for backends with broken ppolicy extension
  handling.

* Obsolete `config_file_version` option was removed.

* Option `reconnection_retries` was removed since it is no longer used. SSSD
  switch to a new architecte of internal IPC between SSSD processes where
responders do not connect to backend anymore and therefore this option is no
  longer used.



--
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to