Slackware introduces PAM into its core

Remember the date! On May 18th of 2020, PAM got added to the Slackware-current core. In case that makes you worry, wonder or causes you to ponder leaving Slackware behind, don’t let this change scare you. PAM has come a long way, it is safe and in Slackware, it is not getting in your way. You won’t have to change a single thing to your computer except installing three new packages (slackpkg install-new) before you reboot. Adding PAM should finally remove the self-imposed writer’s block in Patrick’s mind and open the path to long-awaited renewals in the KDE and XFCE areas.
Ever since these packages were added to /testing, I have been using PAM on my own desktop and laptop, both running Slackware64-current with KDE Plasma5 on top, and the desktop computer also running on Nvidia’s binary drivers. Not a single issue was found here.
Read the announcement:

Mon May 18 19:17:21 UTC 2020
Greetings! After three months in /testing, the PAM merge into the main tree
is now complete. When updating, be sure to install the new pam, cracklib, and
libpwquality packages or you may find yourself locked out of your machine.
Otherwise, these changes should be completely transparent and you shouldn’t
notice any obvious operational differences. Be careful if you make any changes
in /etc/pam.d/ – leaving an extra console logged in while testing PAM config
changes is a recommended standard procedure. Thanks again to Robby Workman,
Vincent Batts, Phantom X, and ivandi for help implementing this. It’s not
done yet and there will be more fine-tuning of the config files, but now we
can move on to build some other updates. Enjoy!

I have already updated my own repositories that are touched by PAM:

    The ‘latest’ and ‘testing’ repositories are now identical and contain the PAM-ified packages.
    It won’t matter which of the two you had configured, you’ll get the PAM-fied packages regardless. If you already were using the PAM from Slackware’s testing combined with my ktown ‘testing’ repository, then there’s nothing you have to change.
    If you did not use PAM before, you will have to do a reinstall of the following ‘ktown’ packages which are the only ones that want to use PAM: kscreenlocker, plasma-workspace and sddm-qt5. And don’t forget to install the new kwallet-pam package.
    I have added ‘compat32’ versions of cracklib, libpwquality and pam, the three packages that got added to Slackware-current today.

And for completeness’ sake, I have also updated the “icu4c-compat” package in my regular repository, just like I did for “boost-compat” last week. Note that these two “compat” packages have no relation to the multilib “compat32” packages!
The boost-compat, icu4c-compat and poppler-compat packages in my regular repository contain older versions of the boost/icu4c/poppler libraries and some of your 3rd party packages (libreoffice!!!) may still need them until their packager does a recompile.

Enjoy! Eric

33 thoughts on “Slackware introduces PAM into its core

  1. For whatever reason, I was expecting that whenever the day did arrive, OpenPAM would be chosen instead of Linux-PAM.


  2. Thanks Eric!
    The upgrade was flawless with your instructions. I had not yet begun to use the new pam packages. But since it was rolled into the tree, I blasted on full speed ahead. I must confess that I had tried this in VBox last week. I didn’t get that one quite right, and I know what to do to fix that now….. 🙂

  3. Eric, you’re a marvel! When reading Pat’s changelog of yesterday I wondered what the adding of PAM would mean for a multilib system. Was about to ask here which new compat32 packages were necessary, only to find that you already had upgraded/added everything related in your multilib repo. Heartfelt thanks.
    Replenishing your beer fund via PayPal seems to be called for (avoid Corona, though 😉 )
    And stay safe.

  4. Bad news for me. I hoped till the last minute that Pat will change his decision. I’m certainly not going to leave Slackware (staying on 14.2 for now). Actually I’m thinking about the creation of PAM-free Slackware fork. Or does any exist already? Unfortunately I don’t have any experience in distro-maintenance, so any help is welcome. I’m ready to do all the compilation and file hosting on my side. Let me know if anybody is eager to help. Thanks.

    1. Good luck is all i can say.
      To be honest, the switch to PAM doesn’t really make any big changes as you expected. It happened in the background and most issues have been tackled during this three months by Pat and the rest of the team + contributors. It’s been a nice seamless merge.

      1. Thanks Willy.
        I’m aware that the changes aren’t really noticeable… for the user. I’m concerned not about how PAM affects users, but on how it affects OS itself. This adds an extra layer of authentication/complexity. It goes against KISS principles imho.
        And I certainly don’t underestimate all that work which was done. My taste just differs in this decision.

  5. Thanks Eric! I’ve been using the PAMified version since PAM landing in testing. Not a single issue so far.

  6. After upgrading the current ChangeLog.txt files, large bold print might highlight the critical necessity of re-installing plasma-workspace. As far as this naive user can tell, there is no difference between pam/no-pam. I do not have to get smart on pam administration. In keeping with Slackware tradition, everything just works!
    Thank you for all the behind-the-scenes work that went into making this happen.

    As for an unnecessary no-pam version, just use the sources to re-compile each of the pamified packages enumerated in ChangeLog.txt. Simply comment out the pammy bits in each of the SlackBuild scripts.

      1. You’re certainly late to the party, or you are someone who does not understand README-encrypted files…

        This line has been part of the ktown README for ages:

        # removepkg kde-workspace

  7. I think that it is also necessary to replace the cracklib and libpwquality of ktown with those of slackware-current.

        1. I think that Pat mistakenly removed python-enum34 because it is still required when building PyQt5 with support for python2. And the PyQt5 package, both mine and the one in Slackware, contains python2 libraries.

          1. Thanks Eric for clarification. I missed the changelog entry on 1st May when python-enum34 was removed from Slackware.
            Sorry for the distraction.

          2. python-enum34 is actually included in the python2-module-collection package. Pat moved all the python2 module parts into a single package as these will not be updated.

    1. Indeed, I realize now that the brotli package was removed from my ktown repository along with hyphen, woff2, qt5-webkit and socat three months ago, but I forgot to remove them from my regular package repository.
      I will do that today.

  8. Just an FYI that the “upgrade” to PAM has gone very smoothly for me so far. The only functional difference I’ve seen is not having to enter my password a second time in Kwallet after logging in. Now THAT is an improvement. 😉

  9. It seems all *.asc files have wrong md5 checksum.
    Nothing can be installed with slackpkg.
    For every package it reports: ERROR – Package not installed! md5sum error!
    Also check fails when verifying with CHECKSUMS.md5

  10. Sorry.
    KTOWN. Latest (and testing).
    update gpg does not help.
    md5sum is actually wrong for .asc files

    tail +13 CHECKSUMS.md5 | md5sum –check:

    ./deps/PyQt5-5.13.2-x86_64-2alien.txz.asc: FAILED
    ./deps/accountsservice-0.6.55-x86_64-1alien.txz.asc: FAILED
    ./deps/grantlee-5.2.0-x86_64-1alien.txz.asc: FAILED
    ./deps/kdsoap-1.9.0-x86_64-1alien.txz.asc: FAILED
    ./deps/mlt-6.20.0-x86_64-1alien.txz.asc: FAILED
    ./kde/applications-extra/calligra-3.2.0-x86_64-1alien.txz.asc: FAILED
    ./kde/applications-extra/kdiagram-2.7.0-x86_64-1alien.txz.asc: FAILED
    ./kde/applications-extra/kpmcore-4.1.0-x86_64-1alien.txz.asc: FAILED

    1. On my mirror server ( aka I do not see your issue, all files check ‘OK’:

      root@bear:/mirrors/alien-kde/current/latest/x86_64# tail +13 CHECKSUMS.md5 | md5sum –check |grep -v OK

      root@bear:/mirrors/alien-kde/current/latest/x86# tail +13 CHECKSUMS.md5 | md5sum –check |grep -v OK

      root@bear:/mirrors/alien-kde/current/testing/x86_64# tail +13 CHECKSUMS.md5 | md5sum –check |grep -v OK

      1. It’s seems it’s problem with mirror.
        I was using, is OK.
        I’ll use this mirror from now on, in the past it was slow, was much faster.
        Thank you.

          1. As far as I can tell, the mirror problem has been fixed. I was able earlier tonight to ‘slackpkg reinstall’ kscreenlocker, plasma-workspace and sddm-qt5, which I was previously unable to do for the same reason mentioned by davjohn. Thanks as always, Eric.

  11. I have upgraded to a PAMmed system and everything works fine except for one thing: if I select automatic connection for SDDM in KDE’s System Settings, which allows to automatically log in with a particular user, I get an Authentification failed by PAM in the SDDM log, while logging in with the same user manually works fine from SDDM.
    Does anyone else have this issue?

    1. Thanks. However, these conf files do not really seem to be endorsed by Eric, not even talking about Pat. I’d prefer to have an approach that Eric is fine with and which keeps the general philosophy of his packages. Some of Eric’s answers seem to imply that the current settings should allow autologin when using non-privileged users, which is exactly what I want to do, I’m not interested in autologin as root. So I thought that maybe I did something wrong in my updates.

      1. I am not against modifying the PAM configurations for SDDM, in fact I am looking at making them more in line with the files Pat added for KDM. That will mean, dropping the login stack and merely using the system-auth stack. With that, also the pam_securetty module will no longer be denying logins for root.
        And then I’ll add a commented-out line showing you how to properly secure your box because I still think logging into a graphical desktop as root is unwise. But… everybody is allowed to shoot himself in the foot. I am not responsible for others hacking your computer.

  12. Hi!
    tried to start wayland session, but got empty screen with blinking cursor (I am running X with NVidia proprietary driver 440.100)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.