PAM about to be merged in -current

Alien Bob · 05-16-2020, 05:13 AM

Quote:

Originally Posted by itsgregman

Wow I never knew Darth created Blue/White64. I ran that for around a year and a half before Slackware proper released a 64 bit version.

It was not Darth Vader who created BlueWhite64. The person who created BlueWhite64 is a Romanian called Attila Craciun (arny is his online moniker).

Alien Bob · 05-16-2020, 05:16 AM

Quote:

Originally Posted by garpu

So what's going to be needed on the user's end when the change happens? life as usual? Anything to keep in mind so we're not locked out after the first reboot? Or is PAM not that way anymore?

Everything will keep working as you are used. You will not have to change, modify or update any configuration.
I have been running a PAM-ified Slackware with PAM-ified Plasma5 on top of it, since it became available and have had zero issues.
That includes all the 3rd party tools I also install and use on this laptop.

chrisretusn · 05-16-2020, 05:30 AM

No worries. I've been using PAM since it was introduced in testing, along with the PAM-ified ktown on my desktop and laptop I use for work with zero issues.

arcadellama · 05-16-2020, 05:38 AM

Quote:

Originally Posted by Didier Spaier

When offered a new toy, the best we can do is learn how to play with it. This could be a good start.

Likely the most helpful post on thread so far. By quick reads of it, it appears to be a relatively simple and well thought out abstraction layer for authentication. I’m not sure the exact use case for needing it — perhaps eliminates the pesky ‘key ring’ business some newer programs want to need.

At any rate, from the documentation, there is this:

Code:

 On a less sensitive computer, one on which the system administrator wishes to remain ignorant of much of the power of Linux-PAM, the following selection of lines (in /etc/pam.d/other) is likely to mimic the historically familiar Linux setup.

#
# default; standard UN*X access
#
auth     required       pam_unix.so
account  required       pam_unix.so
password required       pam_unix.so
session  required       pam_unix.so
       
In general this will provide a starting place for most applications.

I’m not worried. Slackware has never been known for changing just for the sake of changing, or because some engineer at RedHat thinks it’s a good idea.

garpu · 05-16-2020, 07:43 AM

Quote:

Originally Posted by GazL

Yeah, I doubt anyone will have any problems, I was just sharing an old sysadmin's life lesson, i.e. whenever you change anything related to login, ensure you can still login, before you logout.

There are some slight differences I noticed, but I doubt most people will spot them, or care.

Good to know that everything seems to be life as usual... I tend to prepare for the worst, and be pleasantly surprised, nay, shocked, when things work the first time. But I did start using linux in '99...

Poprocks · 05-16-2020, 01:01 PM

I'm not against PAM at all - I used Red Hat based systems for years and just assumed it was a standard component of all GNU/Linux systems until I tried Slackware and learned it was not.

One thing I'm curious about is, what actually NEEDS it versus can just use it's extra plugin-based security functionality on an optional basis?

I'm guessing Kerberos, which in turn is a dependency of so many things.

I'm aware of some software that requires some component of systemd or a drop in replacement thereof, but with PAM I'm less aware of such things. I don't think it's the case that we've had to patch much software to coax it into building without PAM.

I'm the maintainer of the Weston package on SBO (reference implementation of a Wayland compositor) and I've had to patch it to remove PAM as a hard dependency to get it to work. I've had to manually maintain the patch as versions change since the codebase has changed significantly enough, which has been a royal pain. I would hate to have to do that with multiple packages...

teoberi · 05-16-2020, 01:49 PM

I'm a little upset about Dovecot for this:
https://dovecot.org/pipermail/doveco...ch/000436.html

Quote:

Authentication drivers: ..., shadow, ...

In this case the alternative is PAM.

upnort · 05-16-2020, 02:00 PM

Quote:

One thing I'm curious about is, what actually NEEDS it versus can just use it's extra plugin-based security functionality on an optional basis?

The PAM topic has been discussed here several times and in depth. In short, PAM provides Slackware better authentication integration in enterprise environments. PAM is status quo in almost all distros these days.

STDOUBT · 05-16-2020, 03:20 PM

Quote:

Originally Posted by upnort

The PAM topic has been discussed here several times and in depth. In short, PAM provides Slackware better authentication integration in enterprise environments. PAM is status quo in almost all distros these days.

systemd is also "status quo" in almost all distros.
And I think it's obvious to all present that it's a very rare enterprise environment
that includes Slackware _anywhere_.

upnort · 05-16-2020, 03:33 PM

Quote:

And I think it's obvious to all present that it's a very rare enterprise environment that includes Slackware _anywhere_

Possibly. Is including PAM a positive step toward opening such doors?

gus3 · 05-16-2020, 07:42 PM

Quote:

Originally Posted by arcadellama

I’m not sure the exact use case for needing it — perhaps eliminates the pesky ‘key ring’ business some newer programs want to need.

Not just "newer programs". Personal history: I used to work for a company that developed transparent file encryption, as in "decrypt on read, encrypt on write". It worked on individual files, in-place, not filesystems or entire disks. The PAM mechanism was a way to open a user's keybox using the password at login. If the keybox password matched the user's login password, the keys were immediately loaded onto the user's keyring, even before the shell launched. No match simply meant no automatic keybox load; a user could open it manually instead, with a different password.

This was a real and working product in 2004, with products for Red Hat, SuSE, Solaris, AIX, and HP-UX, and was completely independent of any filesystems.

ext4, F2FS, and ubifs now support similar key-based, transparent file encryption/decryption, but it isn't nearly as convenient as the system we had.

dchmelik · 05-17-2020, 12:03 AM

Glad to see it mostly sounds like things will remain as-is (except Dovecot, which I read the post and if it means what I think, I feel extremely disappointed about)... if not the case, I hope PAM is going to be optional (like PulseAudio)... but as I use Dovecot, not sure I have any other choice other than trying something more primitive, less-supported/-documented, and harder to configure, and which may not do as much and may be harder to keep updated/configured, may also be less secure... allowing more security is great, but removing the standard Unix way of doing things isn't (as Dovecot may be doing...?)

bassmadrigal · 05-18-2020, 03:21 PM

It's official, and it should go unnoticed by the vast majority of users. Make sure you slackpkg install-new or manually install pam, cracklib, and libpwquality.

Code:

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!

drgibbon · 05-18-2020, 03:58 PM

Quote:

Originally Posted by bassmadrigal

It's official, and it should go unnoticed by the vast majority of users. Make sure you slackpkg install-new or manually install pam, cracklib, and libpwquality.

Thanks for the heads up.

So what's the story with ktown if we're running the non-testing packages, wait for updates, or just switch straight over to the testing packages?

upnort · 05-18-2020, 03:58 PM

Quote:

Greetings! After three months in /testing, the PAM merge into the main tree is now complete.

The announcement is just too resisting.

Good job Pat!