From Fedora Project Wiki
(Initial draft.)
 
 
Line 33: Line 33:
As we have [https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM dropped the support for NIS(+) in PAM], we are no longer tied to using pam_unix for user authentication.
As we have [https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM dropped the support for NIS(+) in PAM], we are no longer tied to using pam_unix for user authentication.


The code-base of the pam_unix module is full of ancient cruft and really a pain to maintain either for the Fedora downstream maintainers as well for the upstream maintainers of Linux-PAM.  Upstream is currently also considering to replace that module with pam-tcb, waiting for the reception and possible problems - especially the lack of support for NIS(+) - arising with this change proposal.
The code-base of the pam_unix module is full of ancient cruft and really a pain to maintain either for the Fedora downstream maintainers as well as for the upstream maintainers of Linux-PAM.  Upstream is currently also considering to replace that module with pam_tcb, waiting for the reception and possible problems - especially the lack of support for NIS(+) - arising with this change proposal.


While the pam_unix module has about 5090 lines of code and a rather complex set of internally used runtime-configuration flags that need to be maintained and tested on every code change, the pam_tcb basically offers most of the same functionality in about 2280 lines of code and without that much complexity.  The pam_tcb module has been used (and thus has undergone a lot of real-world testing scenarios) since about 20 years in ALT Linux, Mageia (and it's predecessors), and OWL Linux.  The only reason Fedora has not adopted the pam_tcb module long time ago was the circumstance, that it would have needed some heavy patching of glibc (have crypt_gensalt_ra implemented, glibc-upstream refused the patches for NIH), which is not required anymore since we have libxcrypt available.
While the pam_unix module has about 5090 lines of code and a rather complex set of internally used runtime-configuration flags that need to be maintained and tested on every code change, the pam_tcb basically offers most of the same functionality in about 2280 lines of code and without that much complexity.  The pam_tcb module has been used (and thus has undergone a lot of real-world testing scenarios) for about 20 years in ALT Linux, Mageia (and it's predecessors), and OWL Linux.  The only reason Fedora didn't adopt the pam_tcb module earlier was that it would have needed some heavy patching of glibc (have crypt_gensalt_ra implemented, glibc-upstream refused the patches for NIH), which is not required anymore since we have libxcrypt available.


With this change we can also start to decrease the code complexity and configuration complexity in the `shadow-utils` (pam_unix insists on a rather special syntax for getting some of its runtime-configuration from the `login.defs` file) and `libuser` packages.
With this change we can also start to decrease the code complexity and configuration complexity in the `shadow-utils` (pam_unix insists on a rather special syntax for getting some of its runtime-configuration from the `login.defs` file) and `libuser` packages.
Line 95: Line 95:
== Dependencies ==
== Dependencies ==


There are actually no rpms, that directly depend on the change of the functionality of the affected PAM module.  However, the authselect package needs to be updated to use pam_tcb instead of pam_unix; also the pam_ldap module may be explicitly needed for user-authentication using LDAP databases now.
* The authselect package needs to be updated to use pam_tcb instead of pam_unix.
* Some module may be explicitly needed for user-authentication using LDAP databases (pam_ldap, pam_sss...).
* Apart from that there are actually no rpms, that directly depend on the change of the functionality of the affected PAM module.




Line 107: Line 109:
== Documentation ==
== Documentation ==


References to pam_unix should be updated to pam_tcb as applicaable.
References to pam_unix should be updated to pam_tcb as applicable.





Latest revision as of 14:46, 21 October 2021

Replace pam_unix with pam_tcb

Summary

This change is about replacing the pam_unix module with the pam_tcb module.


Owner


Current status

  • Targeted release: Fedora Linux 36
  • Last updated: 2021-10-21
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>


Detailed Description

As we have dropped the support for NIS(+) in PAM, we are no longer tied to using pam_unix for user authentication.

The code-base of the pam_unix module is full of ancient cruft and really a pain to maintain either for the Fedora downstream maintainers as well as for the upstream maintainers of Linux-PAM. Upstream is currently also considering to replace that module with pam_tcb, waiting for the reception and possible problems - especially the lack of support for NIS(+) - arising with this change proposal.

While the pam_unix module has about 5090 lines of code and a rather complex set of internally used runtime-configuration flags that need to be maintained and tested on every code change, the pam_tcb basically offers most of the same functionality in about 2280 lines of code and without that much complexity. The pam_tcb module has been used (and thus has undergone a lot of real-world testing scenarios) for about 20 years in ALT Linux, Mageia (and it's predecessors), and OWL Linux. The only reason Fedora didn't adopt the pam_tcb module earlier was that it would have needed some heavy patching of glibc (have crypt_gensalt_ra implemented, glibc-upstream refused the patches for NIH), which is not required anymore since we have libxcrypt available.

With this change we can also start to decrease the code complexity and configuration complexity in the shadow-utils (pam_unix insists on a rather special syntax for getting some of its runtime-configuration from the login.defs file) and libuser packages.


Feedback

No feedback yet.


Benefit to Fedora

Implementing this change will require less effort in maintainance and configuration of local user authentication, especially when it comes to updating (or implementing new) hashing methods for user passphrases in the future; most things can be done by just editing a single line in the configuration instead of aligning, backporting and applying patches to several hundred lines of code to make it work, the real work just needs to be done in libxcrypt upstream.


Scope

  • Proposal owners:
    • Adapt the pam spec file to build without the pam_unix module, and to runtime-require the external pam_tcb module.
    • Communicate the needed changes of the PAM configuration for user-authentication with the authselect maintainers; also offer assistance to implement the needed changes.
  • Other developers:
    • Help reviewing the tcb package for inclusion in the Fedora package repository.
    • Apply the pull-request to the authselect package.
    • Test this change.
  • Release engineering: [1]
  • 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

There shouldn't be any impact besides the implications coming with the lack of user-authentication using NIS(+).


How To Test

  • local system users:
    • Try to login with a local user account.
    • Use su and/or sudo to get super-user powers.
    • If there are no regressions, things should be fine.
  • system users provided by LDAP or similar
    • Try to login with a user account provided over LDAP.
    • Use su and/or sudo to get super-user powers.
    • If there are no regressions, things should be fine.


User Experience

There are no visible changes for users, except the lack of user-authentication using NIS(+).


Dependencies

  • The authselect package needs to be updated to use pam_tcb instead of pam_unix.
  • Some module may be explicitly needed for user-authentication using LDAP databases (pam_ldap, pam_sss...).
  • Apart from that there are actually no rpms, that directly depend on the change of the functionality of the affected PAM module.


Contingency Plan

  • Contingency mechanism: Revert the changes made to the affected packages and rebuild them.
  • Contingency deadline: At beta freeze.
  • Blocks release? Yes.


Documentation

References to pam_unix should be updated to pam_tcb as applicable.


Release Notes

The pam_unix module has been replaced with the pam_tcb module.