FS#42273 - [pambase] Auxiliary service files are needlessly convoluted
Attached to Project:
Arch Linux
Opened by Patrick Goetz (pgoetz) - Monday, 06 October 2014, 21:25 GMT
Last edited by freswa (frederik) - Tuesday, 24 March 2020, 19:02 GMT
Opened by Patrick Goetz (pgoetz) - Monday, 06 October 2014, 21:25 GMT
Last edited by freswa (frederik) - Tuesday, 24 March 2020, 19:02 GMT
|
Details
Description: Auxiliary service files in pambase are
needlessly convoluted, which makes them confusing to work
with, increasing the likelihood of introducing a privilege
granting error. For example, /etc/pam.d/system-local-login
includes system-login for each service type:
--------------------------------- # pwd /etc/pam.d # cat system-local-login #%PAM-1.0 auth include system-login account include system-login password include system-login session include system-login --------------------------------- However, /etc/pam.d/system-login is itself composed of multiple service types: --------------------------------- # cat system-login #%PAM-1.0 auth required pam_tally2.so deny=3 unlock_time=60 onerr=succeed file=/var/log/faillog auth required pam_shells.so auth requisite pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_loginuid.so session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so dir=/var/spool/mail standard quiet -session optional pam_systemd.so session required pam_env.so --------------------------------- This means, for example that auth requisite pam_nologin.so is being included here: session include system-login Note further the inclusion of system-auth under each management group type in system-login. This is yet another auxiliary file with multiple management group types! It becomes quite complicated to sort out what each stack of pam module rules actually is. Obviously this works (hence severity of but = Low), but this is poor configuration management and makes it much harder to add/remove service modules effectively. Suggestion: Follow the Ubuntu/Debian style for auxiliary service files. Create something like common-auth, common-account, etc. for each management group type, and then include these in the service files when necessary; for example: # pwd /etc/pam.d # cat smtp # PAM configuration file for Postfix SMTP service @include common-auth @include common-account Additional info: * package version: 20130928-1 |
This task depends upon
Closed by freswa (frederik)
Tuesday, 24 March 2020, 19:02 GMT
Reason for closing: None
Additional comments about closing: This seems pretty stalled to me. If it's still an issue, please fill a re-open request. Thank you :)
Tuesday, 24 March 2020, 19:02 GMT
Reason for closing: None
Additional comments about closing: This seems pretty stalled to me. If it's still an issue, please fill a re-open request. Thank you :)
Here is an example of what I'm talking about. I traced the unmodified stack of modules for the login service from the util-linux package, and assembled them based on where they came from:
--------------------------------------
# login
auth required pam_securetty.so
auth requisite pam_nologin.so
# system-local-login
# system-login
auth required pam_tally2.so deny=3 unlock_time=60 onerr=succeed file=/var/ log/faillog
auth required pam_shells.so
auth requisite pam_nologin.so
# system-auth
auth required pam_unix.so try_first_pass nullok
auth optional pam_permit.so
auth required pam_env.so
--------------------------------------
Notice that the pam_nologin.so module is repeated. Even core package maintainers are having trouble keeping this straight!