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: pbrezina@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.
On Tue, Oct 12, 2021 at 11:33 AM Ben Cotton bcotton@redhat.com wrote:
=== 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.
PAM gained support for systemd-style overlay configuration some time ago. Actually a number of core system components did, if the libeconf dependency is turned on. Instead of forcing authselect, we should probably make sure base functional configuration is shipped in something like /usr/share/pam/pam.d or something like that.
Not that I think authselect is bad, but I think it's a bad hammer to solve this problem.
-- 真実はいつも一つ!/ Always, there's only one truth!
This change is well-considered and includes detailed reasoning to support it. Looks good to me.
I think the change proposal should be renamed, though, since authselect would clearly not *actually* be mandatory. Of course you'll risk severe breakage if you turn it off and edit these low-level configurations directly, but that is really no different than it was before.
On Tue, Oct 12 2021 at 11:45:28 AM -0400, Neal Gompa ngompa13@gmail.com wrote:
PAM gained support for systemd-style overlay configuration some time ago. Actually a number of core system components did, if the libeconf dependency is turned on. Instead of forcing authselect, we should probably make sure base functional configuration is shipped in something like /usr/share/pam/pam.d or something like that.
That is not possible with nsswitch.conf, though. This proposal is a good solution to the problems we've had with correctly maintaining nsswitch.conf. The status quo (see "Therefore we can split users into four groups:" in the change proposal) is just not good compared to Fedora's usual quality standards, and this change proposal would address all of the problems we've had. Also, I'm pretty sure the scriptlets we currently rely on to maintain correct configurations just do not work at all on Silverblue/Kinoite/CoreOS (where editing /etc in RPM scriplets just does not work), and I suspect nobody really knows what the situation there is for users who have upgraded from older releases.
Michael
On Tue, Oct 12, 2021 at 1:13 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
This change is well-considered and includes detailed reasoning to support it. Looks good to me.
I think the change proposal should be renamed, though, since authselect would clearly not *actually* be mandatory. Of course you'll risk severe breakage if you turn it off and edit these low-level configurations directly, but that is really no different than it was before.
On Tue, Oct 12 2021 at 11:45:28 AM -0400, Neal Gompa ngompa13@gmail.com wrote:
PAM gained support for systemd-style overlay configuration some time ago. Actually a number of core system components did, if the libeconf dependency is turned on. Instead of forcing authselect, we should probably make sure base functional configuration is shipped in something like /usr/share/pam/pam.d or something like that.
That is not possible with nsswitch.conf, though. This proposal is a good solution to the problems we've had with correctly maintaining nsswitch.conf. The status quo (see "Therefore we can split users into four groups:" in the change proposal) is just not good compared to Fedora's usual quality standards, and this change proposal would address all of the problems we've had. Also, I'm pretty sure the scriptlets we currently rely on to maintain correct configurations just do not work at all on Silverblue/Kinoite/CoreOS (where editing /etc in RPM scriplets just does not work), and I suspect nobody really knows what the situation there is for users who have upgraded from older releases.
Why hasn't the nsswitch.conf situation been fixed to work in /usr/share like it does in /etc?
On Tue, Oct 12 2021 at 01:44:12 PM -0400, Neal Gompa ngompa13@gmail.com wrote:
Why hasn't the nsswitch.conf situation been fixed to work in /usr/share like it does in /etc?
Guess: probably nobody proposed it to the glibc developers yet.
Michael
On 10/12/21 7:12 PM, Michael Catanzaro wrote:
This change is well-considered and includes detailed reasoning to support it. Looks good to me.
I think the change proposal should be renamed, though, since authselect would clearly not *actually* be mandatory. Of course you'll risk severe breakage if you turn it off and edit these low-level configurations directly, but that is really no different than it was before.
Do you have any proposals on the name?
To me, this change means that if you don't use authselect, you are basically on your own and I'd like to stress this as much as possible.
But yes, it is still possible to opt-out. However, the package maintainers won't (should not) care about non-authselect configuration anymore.
On Thu, Oct 14 2021 at 01:28:23 PM +0200, Pavel Březina pbrezina@redhat.com wrote:
Do you have any proposals on the name?
To me, this change means that if you don't use authselect, you are basically on your own and I'd like to stress this as much as possible.
Enforce Authselect Configuration Consistency?
Dne 12. 10. 21 v 17:45 Neal Gompa napsal(a):
On Tue, Oct 12, 2021 at 11:33 AM Ben Cotton bcotton@redhat.com wrote:
=== 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.
PAM gained support for systemd-style overlay configuration some time ago. Actually a number of core system components did, if the libeconf dependency is turned on. Instead of forcing authselect, we should probably make sure base functional configuration is shipped in something like /usr/share/pam/pam.d or something like that.
Not that I think authselect is bad, but I think it's a bad hammer to solve this problem.
Right, the best would be if all the "configuration" files were removed from /etc. I have never had a need to change the configurations, but I had to fix those files several times.
Vít
On 10/12/21 5:45 PM, Neal Gompa wrote:
On Tue, Oct 12, 2021 at 11:33 AM Ben Cotton bcotton@redhat.com wrote:
=== 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.
PAM gained support for systemd-style overlay configuration some time ago. Actually a number of core system components did, if the libeconf dependency is turned on. Instead of forcing authselect, we should probably make sure base functional configuration is shipped in something like /usr/share/pam/pam.d or something like that.
This way, it would be possible to update the *default* configuration. If the configuration is modified (e.g. added fingerprint support) the user config won't be updted, but still possible with authselect.
Packages would still have to use difficult scriptlets to enable/disable their modules. With authselect, they can just call "authselect enable-feature with-fingerprint" and fingerprint will be enabled if the profile supports it.
Note: imho packages should not do these kind of changes and rather explain how to enable modules in documentation, but they are doing it.
Not that I think authselect is bad, but I think it's a bad hammer to solve this problem.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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: pbrezina@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
On Wed, Oct 13 2021 at 10:22:14 AM +0200, Hans de Goede hdegoede@redhat.com wrote:
Making what IMHO is a poor default of always using sssd everywhere hardcoded even deeper into Fedora seems like a bad idea to me.
I think we can fix this at the same time. Make authselect default to its minimal profile rather than its sssd profile, and make realmd responsible for running authselect to enable the sssd profile when it is required. I think realmd is already capable of installing the dependencies it needs when enabled, right? This way, most Fedora systems would no longer run sssd, but enabling enterprise login would not require manual configuration for those who need it.
Michael
On 10/13/21 3:17 PM, Michael Catanzaro wrote:
On Wed, Oct 13 2021 at 10:22:14 AM +0200, Hans de Goede hdegoede@redhat.com wrote:
Making what IMHO is a poor default of always using sssd everywhere hardcoded even deeper into Fedora seems like a bad idea to me.
I think we can fix this at the same time. Make authselect default to its minimal profile rather than its sssd profile, and make realmd responsible for running authselect to enable the sssd profile when it is required. I think realmd is already capable of installing the dependencies it needs when enabled, right? This way, most Fedora systems would no longer run sssd, but enabling enterprise login would not require manual configuration for those who need it.
Minimal profile is really minimal and does not provide almost any flexibility so imho it should not be used as a default. We could however create a new profile e.g. "local".
SSSD is default because it was serving local users as well. This in no longer true since F35 [1], so there is certainly a possibility to switch the default, if the community desires it and it is certainly beneficial to do it together with this change.
I don't see a strong reason to change the default profile. Local users go through nss_files and pam_unix, if SSSD is not running it does not do anything.
That being said, if there is a strong desire to create a non-sssd profile for local users only, I will definitely not oppose it. Please, create a change page (needs to be system-wide since changes in anaconda are required), if accepted I can implement required changes or review a pull request.
The reason why I'd like to have separate change for this is that 1) "Make authselect mandatory" will use whatever default is chosen 2) Either change can be accepted or refused 3) Discussion will be restricted to one topic.
Thank you, Pavel
[1] https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache
Michael
Hi Pavel,
On 10/14/21 12:57 PM, Pavel Březina wrote:
On 10/13/21 3:17 PM, Michael Catanzaro wrote:
On Wed, Oct 13 2021 at 10:22:14 AM +0200, Hans de Goede hdegoede@redhat.com wrote:
Making what IMHO is a poor default of always using sssd everywhere hardcoded even deeper into Fedora seems like a bad idea to me.
I think we can fix this at the same time. Make authselect default to its minimal profile rather than its sssd profile, and make realmd responsible for running authselect to enable the sssd profile when it is required. I think realmd is already capable of installing the dependencies it needs when enabled, right? This way, most Fedora systems would no longer run sssd, but enabling enterprise login would not require manual configuration for those who need it.
Minimal profile is really minimal and does not provide almost any flexibility so imho it should not be used as a default. We could however create a new profile e.g. "local".
SSSD is default because it was serving local users as well. This in no longer true since F35 [1], so there is certainly a possibility to switch the default, if the community desires it and it is certainly beneficial to do it together with this change.
I don't see a strong reason to change the default profile. Local users go through nss_files and pam_unix, if SSSD is not running it does not do anything.
Sorry, I somehow completely missed the F35 change to make files the first entry in nssswitch.conf by default now.
I see on the changes (1) page that SSSD now also no longer is started by default, that is great.
Since SSSD already no longer runs by default, then I see no need for a special "local" profile.
Thank you for your work on this!
Regards,
Hans
1) https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache
On Tue, Oct 12, 2021, at 11:32 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
Just to raise the visibility here, this currently breaks all ostree-based systems (*again*):