F40 Change Proposal: Removing SSSD ‘files provider’ (System-Wide)

Project Discussion Change Proposals
,
1

:link: Removing SSSD ‘files provider’

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Announced
Wiki

:link: Summary

Remove SSSD “files provider” feature that allows handling of local users.

:link: Owner

:link: Detailed Description

SSSD ability to handle local users (/etc/passwd and /etc/group) using “id_provider=files” was previously deprecated and future removal announced both upstream and in Fedora 38 RNs.
FlexibleLocalUserCache change disabled this feature by default even earlier. The reason for this movement is that benefits of the feature appeared to be negligible, while confusion and overhead it creates is considerable.
Practically, there are only two use cases that currently justify usage of “files provider”:

  • smart card authentication of local users;
  • session recording for local users.

For both cases “proxy provider” is a viable substitute, so “files provider” can be dropped. SSSD maintainers will provide a document on sssd.io describing how to switch (where it’s really needed!)

:link: Feedback

So far we received no pushback (and practically no feedback at all) with regards to previous deprecation notices and removal announcements.

:link: Benefit to Fedora

Alignment with upstream development that plans to remove corresponding code completely. Cleaner/simpler OS configuration (/etc/nsswitch.conf and authselect profiles).

:link: Scope

  • Proposal owners:

    • SSSD package will be built without --with-files-provider ./configure option; document describing usage of ‘proxy provider’ in aforementioned cases will be provided;
    • authselect
      • New “local” profile to handle local users without SSSD will be introduced. This profile will be based on “minimal”, but it may gain more features.
      • “minimal” profile will be removed and replaced by “local”.
      • “Local” profile will be now the default profile
      • ‘sssd’ profile will lose with-files-domain and with-files-access-provider options, and will gain --with-tlog option.

  • Other developers:

    • cockpit session recording: configuration of session recording with local users was switched to ‘proxy-provider’, change will be made to execute authselect –with-tlog;
    • shadow-utils: package will be built with --without-sssd configuration option set.

  • Release engineering: #11765 (proposed composes definition change)

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives: N/A

:link: Upgrade/compatibility impact

Since the feature was turned off by default since Fedora 35 (FlexibleLocalUserCache), this change won’t have any noticeable impact on the vast majority of the user base.
Those who were configuring it explicitly and for a good reason, will have to update SSSD configuration manually to use ‘proxy provider’ instead of ‘files provider’.

:link: How To Test

General regression testing.

:link: User Experience

N/A

:link: Dependencies

sssd, authselect, cockpit-session-recording, shadow-utils

:link: Contingency Plan

  • Contingency mechanism: revert SSSD spec file changes
  • Contingency deadline: Fedora 40 beta freeze
  • Blocks release? No

:link: Documentation

Release notes only.

:link: Release Notes

Previously deprecated SSSD “files provider” feature that allows handling of local users was removed. This doesn’t affect default configuration where local users are handled by glibc module (‘libnss_files.so.2’) In case of specific configuration that requires SSSD to handle local users (like, for example, smart card authentication of local users) switch to ‘proxy provider’ instead.

2

This change proposal has now been submitted to FESCo with ticket #3107 for voting.

To find out more, please visit our Changes Policy documentation.

3

Actually, this is pretty interesting, I have been thinking on disabling some services I didn’t use and I came upon sssd.
Since it is actually used for authselect but my system is a single-user system, I actually wasn’t very sure on whether it made sense to migrate to the minimal profile.

So I have a few questions about the authselect config in relation to sssd.

Those are the profiles:

$ authselect list
- minimal	 Local users only for minimal installations
- nis    	 Enable NIS for system authentication
- sssd   	 Enable SSSD for system authentication (also for local users only)
- winbind	 Enable winbind for system authentication

Those are the minimal profile features:

$ authselect list-features minimal
with-ecryptfs
with-faillock
with-mdns4
with-mdns6
with-mkhomedir
with-pamaccess
with-pwhistory
with-silent-lastlog
with-systemd-homed
without-nullok

And these are the sssd features:

$ authselect list-features sssd
with-ecryptfs
with-faillock
with-files-access-provider
with-files-domain
with-fingerprint
with-gssapi
with-libvirt
with-mdns4
with-mdns6
with-mkhomedir
with-pam-gnome-keyring
with-pam-u2f
with-pam-u2f-2fa
with-pamaccess
with-pwhistory
with-silent-lastlog
with-smartcard
with-smartcard-lock-on-removal
with-smartcard-required
with-subid
with-sudo
with-systemd-homed
without-nullok
without-pam-u2f-nouserok

And finally this is my current authselect config, which I believe is the default as I believe I never changed it:

$ authselect current
ID do perfil: sssd
Recursos habilitados:
- with-silent-lastlog
- with-mdns4
- with-fingerprint

As far as I can see the two main features that the minimal profile lacks but sssd profile has are fingerprint support (which was actually one of the causes of issues with the authselect migration IIRC) and pam u2f support (used for, for example, Yubikey support, although the Yubikey guide recommends setting up manually instead of using authselect).

Will those two be preserved after the change? Would that also allow sssd to be completely disabled and potentially also removed in the future for a system with only local users?

4

Hi, yes this is the plan. We will issue a new “local” profile that will support everything meaningful for local users (meaning fingerprint and pam_u2f as well). At the same time, this profile will render the minimal profile obsolete so that will be removed.