The only thing I could not get working with Slackware that I had working in Buster on my X270 Lenovo was the fingerprint reader unlock. I consciously decided not to bastardize a PAM install in Slackware. If this gets integrated I could get it working again

1 members found this post helpful.

Well, ivandi's implementation was a minimal viable product: there may be other packages that need be recompiled for "full" integration, so if PV does it he might go all the way or go the minimal route as well.

Kerberos will hook itself into PAM and also things like CUPS and email servers and clients... BIND I think will pick it up, but not a huge number of packages (I may be wrong).

In other words: it's not easy to maintain 2 versions of these packages (with PAM/krb5 and without PAM/krb5) and PV will probably pick one and stick with it.

That being said, there is a version of several packages without pulse-audio officialy maintained ... so anything is possible :-)

If we do the krb5/PAM, don't expect any support for not running it. It'll be mandatory unless you wish to figure out what and how to recompile and reconfigure everything needed to get rid of it.

That said, if it is added I expect to make it so that you won't even notice that it's there. So unlike PA, for example, there shouldn't really be any scenarios where certain things do not work as well because the system has krb5/PAM.

24 members found this post helpful.

Expectations exceeded once again PV.

2 members found this post helpful.

I read on Mastodon that this was updated today: http://www.slackware.com/~vbatts/pam/
EDIT: Direct Link to the post https://fosstodon.org/@vbatts/103121141271590932

2 members found this post helpful.

I respectively disagree, its a lot of increased complexity deep in the software stack for niche features that I personally do not want to work (On my system).

2 members found this post helpful.

From what I know, those "niche features" are present on any medium or major Linux distribution. In fact, I do not heard about a reasonable known distribution other than Slackware to have today this lack of PAM and Kerberos. Even CRUX have PAM today.

So, either you have a very personal and eccentric interpretation of the words "niche features", either your words are intended to mislead the people...

5 members found this post helpful.

Slackware has resisted PAM for decades, and it's something that distinguishes it from other distributions. I can't think of others offhand that don't use it. (even LFS if you follow the BLFS procedure after the base system... I don't)

I don't care about Microsoft Networking (Active Directory, specifically) or "enterprise" buzzwords, and I don't like the complexity of PAM modules and policies getting in my way, and I don't like the system wide dependencies on it, and likewise kerberos. It's only really NEEDED (as in, can't work around it) for niche uses. We have gotten along without it nicely, thus far.

It is going to be a very divisive change and I certainly will know it's there, because it changes the way we do things.

I have no strong feeling about PAM either way. My only question is why now?

What changes? This may just be because I am naive about it and haven't seriously used any distros other than Slackware for quite some time, but my understanding (from other posts on this forum who have used systems with PAM) is that for those who have local login systems, the change is pretty much unnoticeable. It just opens up the possibilities for various things like fingerprint readers or using it in a larger corporate settings with network logins.

But I am all for having my misconceptions corrected, so in what way would PAM/krb5 change the way we do things?

6 members found this post helpful.

Yeah, I agree. There are a lot of things that could be argued add a lot of "complexity" and create "system-wide dependencies" (or close to it) that we have all accepted and have no problem with. X is one example. I personally don't have a need for PAM/kerberos, but if it makes Slackware more appealing to a broader audience that needs the functionality, I am all for it. As you said, though, it would be interesting to hear actual technical -- as opposed to philosophical -- reasons against it.

2 members found this post helpful.

PAM modules and policies for different login types, limits enforced through PAM, system wide dependencies we can't break etc.

I get that having PAM will make things easier for a lot of people (including package builders that have to adapt to a system without PAM by faking with PAM headers and stuff) so I'll grudgingly bear the change, but let's not pretend that it won't change anything.

By this time, any security-related code that doesn't use PAM is much less thoroughly tested than the code that does.

6 members found this post helpful.

I'll echo bassmadrigal and montagdude and ask it again: what EXACTLY will it change?
Even PV said he'd implement it in a way that users would not even notice it was there... and I think most users wouldn't

I am not a member of that "most users" group and it's not really within the scope of this discussion to explain system administration. For that, you could go read some tutorials on PAM to see how it will be different.

The biggest thing for me is that applications and libraries are compiled against PAM, and thus require it. I know, "what's the difference, we already have dependencies for other things". Just one more thing to break your system, that's all.

Misconfiguration or missing configuration will also lock you out of your own system too, and it's more difficult to recover than with plain /etc/passwd and shadow without the middle man.

Whether you think that matters or not, it changes the way we do things.

1 members found this post helpful.