Hi, On 10/12/21 5:32 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory > > == Summary == > This change wants to make authselect required to configure > authentication and identity sources and forcefully update > non-authselect configuration to the sssd authselect profile to > eliminate any existing non-authselect setups. > > Even though it will still be possible to manually modify the > configuration, users that require special configuration should create > and use custom authselect profile. > > ''Authselect is available in Fedora since Fedora 27 and enabled by > default on new installations since Fedora 28. Authconfig compatibility > tool was removed from Fedora 35 as a > [[Changes/RemoveAuthselectCompatPackage|system wide change page]]. It > is now well accepted by the community as well as the package > maintainers. The package maintainers have repeatedly requested to make > authselect mandatory for the users which lead to creation of > [https://bugzilla.redhat.com/show_bug.cgi?id=2000936 this bugzilla].'' > > == Owner == > * Name: [[User:pbrezina|Pavel Březina]] > * Email: pbrez...@redhat.com > > > == Detailed Description == > The following components must be updated to make authselect mandatory: > * authselect > * pam > * glibc > * packages that use it: systemd, ecryptfs, nss-mdns and fingerprint. > > > Required changes: > # Remove user-nsswitch.conf functionality from authselect > # Move ownership of /etc/nsswitch.conf and /etc/pam.d/{system-auth, > password-auth, smartcard-auth, fingerprint-auth, postlogin} to > authselect from glibc and pam > # Require authselect in pam > # Remove non-authselect support from systemd, ecryptfs, nss-mdns and > fingerprint > # Select default profile when authselect is installed > # Select default profile when authselect is upgraded > > === Remove user-nsswitch.conf functionality === > File /etc/authselect/user-nsswitch.conf was introduced in authselect > to allow partial user modifications of nsswitch.conf without the need > to create a custom authselect profile. The main driver was to enable > modules that are not included in authselect such as systemd-resolved > and nss-mdns. > > This however made the situation more confusing to users and it is not > desirable any more if authselect is mandatory. > > '''Authselect will drop user-nsswitch.conf functionality and instead > add more nsswitch modules to existing profiles and be more open about > future inclusion requests.''' > > === Own /etc/nsswitch.conf and /etc/pam.d/{system-auth, password-auth, > smartcard-auth, fingerprint-auth, postlogin} instead of glibc and pam > === > File /etc/nsswitch.conf is currently owned by glibc. It will be now > owned by authselect and removed from glibc. > > PAM configuration generated by authselect is currently owned by pam. > It will be now owned by authselect and removed from pam. > > ''Note: that config-util and other will still be owned by pam since > these files are not generated by authselect.'' > > '''All files that are generated by authselect are now owned by authselect.''' > > === Require authselect in pam === > The pam package will require authselect. This will tie pam and > authselect together and it will be impossible to uninstall authselect > without uninstalling pam which fundamentally makes authselect a hard > dependency on each system. > > '''This step will make it impossible to uninstall authselect, making > it always available to RPM packages.''' > > === Remove non-authselect support from systemd, ecryptfs, nss-mdns and > fingerprint === > '''Non-authselect configuration support will be dropped in these packages.''' > > === Select default profile when authselect is installed === > If authselect configuration is not detected and this is a new > installation of authselect it will automatically select the > distribution default authselect profile by calling authselect select > --force with distribution specific parameters. > > If existing authselect configuration is detected (perhaps from > previous installation), it will be updated (current behavior). > > This makes sure that if authselect is installed (which is always) a > configuration is created. > Select default profile when authselect is upgraded > If authselect is upgraded from an older version and non-authselect > configuration is detected, it will forcefully overwrite it with > distribution defaults by calling authselect select --force with > distribution specific parameters. > > This is a one time event so if someone does not want to use > authselect, it remains possible. However, non-authselect > configurations will not be supported by RPM packages mentioned above. > > If authselect is upgraded on a system that already is configured by > it, the update process remains the same as it is now. > > '''This step will forcefully update existing installations to > authselect configuration. It is a one time event and opt-out is still > possible but no longer supported. > ''' > > == Benefit to Fedora == > '''Making authselect mandatory will provide better user and > maintainers experience and significantly reduce risk of breaking > system configuration.''' > > The use of authselect-generated configuration is currently optional. > This means that users can uninstall authselect or just opt-out from it > by modifying the PAM and nsswitch.conf manually. > > Additionally users that upgrade from pre-authselect systems (Fedora 27 > and older) must opt-in to authselect manually, which is not the case > most of the time. Also sometimes an upgrade of a particular package > that did not handle authselect configuration correctly automatically > opted-out its users. Therefore we can split users into four groups: > * Those who are using authselect > * Those who were using authselect but are not anymore due to various > errors in packages > * Those who are not using authselect because they are not aware of it > and upgraded from older Fedora versions thus it was not automatically > enabled > * Those who are not using authselect knowingly > > ''Fedora is now split into two worlds: those who use authselect and > those who don’t. This however keeps two problems existing. Authselect > was designed to solve them both. But it will be solved only if the use > of authselect is a mandatory requirement.'' > > === 1. It is difficult to deliver updates to configurations === > FIles /etc/nsswitch.conf and /etc/pam.d/* are distributed as > %config(noreplace) which means that they are configuration files and > are only installed if they are not yet present. If they are present > then they are never overwritten with package updates, instead an > *.rpmnew file is created and the update responsibility is left > completely to the user. > > It is done this way to prevent overwriting user changes > configurations. But at the same time it means that even configurations > that are not modified by the users can not be changed so we can not > deliver fixes and changes efficiently. > > It is only possible through difficult scriptlets. As an example, we > can show this bugzilla where a change in Gnome required an update to > PAM otherwise the user could not authenticate. Delivering the change > was easy with authselect, but difficult for non-authselect systems. > > Authselect already knows how the resulting configuration should look > and does not risk overriding user configuration. Making it mandatory > will help distribute important updates to nsswitch and PAM > configuration. > > === 2. Package maintainers wants to enable/disable nsswitch or PAM > modules automatically upon installation/uninstallation === > Packages that install nsswitch modules (e.g. systemd, nss-mdns) or PAM > modules (e.g. ecryptfs, fprintd) want to enable the module > automatically upon RPM installation to provide a better user > experience. So they use various more or less complex and fragile > scriptlets in %post action of the RPM. > > This is usually easier for the nsswitch module, when simple sed works > for most configurations. But it is not really possible for PAM > (because there is high risk of introducing security vulnerabilities or > breaking authentication completely) so the packages used authconfig > and now authselect. > > Packages need to detect the current authselect state and either call > authselect when available or fallback to non-authselect scriptlets. > The end results tends to be the same for nsswitch modules but > different for PAM modules where it is either enabled with authselect > or nothing happens. > > '''If authselect is made mandatory, packages can only support > authselect configuration which makes the change simple, > straightforward, easier to test and safe.''' > > == Scope == > * Proposal owners: > ** authselect maintainers: > *** implement the changes described in "Detailed Description" in all > affected packages > *** open pull requests with the changes against affected packages > > * Other developers: > ** maintainers of affected packages must accept submitted merge request > > * Release engineering: [https://pagure.io/releng/issue/10337 #10337] > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: N/A > > == Upgrade/compatibility impact == > The system will be forcefully configured with authselect, selecting > the default distribution profile (sssd), if non-authselect > configuration is detected. It will will override users configuration. > A backup will be created, users can run 'authselect backup-restore > $id' to restore their configuration when desired. > > == How To Test == > * Authselect must keep working as expected. > * Ownership of the following files is transferred to authselect-libs package > ** /etc/pam.d/fingerprint-auth > ** /etc/pam.d/password-auth > ** /etc/pam.d/postlogin > ** /etc/pam.d/smartcard-auth > ** /etc/pam.d/system-auth > ** /etc/nsswitch.conf > * pam requires authselect > * updating from previous system with non-authselect configuration must > result in applied authselect configuration with sssd profile > * updating from previous system with authselect configuration must > remain intact (besides applying udated profiles) > * installing/removing affected packages (see Detailed Description) > must not break authselect configuration > > == User Experience == > PAM and nsswitch.conf configuration will be automatically updated when > changed. > > ''Note: To request inclusion of a new nsswitch or PAM module in > default authselect profiles, either open an issue on authselect GitHub > project or open a bug against authselect component in Fedora > bugzilla.'' > > ''Note: Users will still be able to create custom profiles to include > modules that are not supported by default authselect profiles. > However, such profiles will have limited update support. It is > possible to create a custom profile with some files as symlinks to > default profiles, those files will receive updates automatically. > However, modified files of the custom profiles still need to be > updated manually and the users are responsible for the update. > '' > > ''Note: Users will still be able to opt-out from authselect, but such > configuration will no longer be updated on upgrades or touched by > package installation.'' > > == Dependencies == > This change does not break any packages that depends on authselect. > > == Contingency Plan == > * Contingency mechanism: Revert changes in affected packages. > * Contingency deadline: Beta > * Blocks release? No > > == Documentation == > There is no upstream documentation. > > == Release Notes == > Configuring system authentication and identity sources with authselect > is now mandatory. Systems with non-authselect configuration will be > automatically forcefully upgraded to authselect configuration. Users > that require special configuration are encouraged to create and use > custom authselect profile.
I'm all in favor of having less moving parts as this proposal suggest, but can we first please re-consider using sssd by default everywhere? For 99.9% of our users it does not add any used functionality, it is really just bloat (even if it is small bloat). For example shows up in powertop-s list of processes causing CPU wakeups on a fully idle system (likely because it itself is woken by some other process though). I've been running all my personal systems with "authselect select minimal" for 2 Fedora release cycles now without any issues. Making what IMHO is a poor default of always using sssd everywhere hardcoded even deeper into Fedora seems like a bad idea to me. Regards, Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
