I'm not a pam lover, but I think tha the next stable release (14.2 or 15.0) should be linked to pam.

Slackware already contains pam, in /extra, but is only for additional packages. I can't use ssh with pam.
Really, I don't like pam, but some authentication schema (ldap for example) does not work without it

Slackware 14.1 will not have PAM in its /extra directory. The pam library was needed in Slackware 14.0 for google-chrome, but that requirement has been dropped, so the pam stuff was removed a while ago.

As for Slackware 15... who says there won't be a 14.2 , 14.3, ...? And Using PAM with LDAP is left as an exercise for the reader.

Eric

2 members found this post helpful.

PAM really is a headache and is known to break systems. It's best to leave it out of a system unless it's a truly required dependency.

Although MATE also need PAM for mate-screensaver package in order to be able to lock the desktop (and this is a very important feature for most users), we decided not to put PAM in the base/extra directory, but placed it on testing/ and we don't build the package on this and leave it to users if they want to use it.

3 members found this post helpful.

I think there may be another way to get ldap authentication without dirtying hands with PAM. It seems like it has a static implementation of PAM included inside it, enough to do ldap auth. It is in salckbuilds: http://slackbuilds.org/repository/14...nss-pam-ldapd/

I haven't had time to look at it yet, so i can't say much about it. However it doesn't seem to depend on anything outside the base, which sounds like it could make a fairly clean solution for ldap auth.

Sorry if this thread is too old for my post, but somebody may stumble on it and it may be useful.

4 members found this post helpful.

OpenLDAP only requires PAM if compiled for it, otherwise it doesn't use or need it. It's entirely optional. PAM takes a lot to setup and configure as well as many packages require a PAM configuration script.

Unless you seriously want to play around with PAM, go right ahead, but if you get locked out of root for whatever reason, don't say you weren't warned.

1 members found this post helpful.

Do the reasons that took PV to dislike PAM back in the day still apply today?
(I guess only PV can really answer this one hehehe)

It might be time to consider including PAM, since it does indeed offer some very useful functionality. On the other hand, it's really easy to retrofit PAM to a Slackware system (install PAM, make create a system-auth file in /etc/pam.d, rebuild shadow), so I'm not sure the need is all that great.
I'm not trying to start an argument here, but what kind of breakage have you seen? Most of my Slackware systems are PAM-ified and I've been doing that for years. I've had no issues so far.

I've seen things as bad as accounts becoming completely locked to where logging in is forbidden, even to the root user resulting in a total lock-out requiring a chroot via a rescue disk, and a lot of work to reset PAM back to TRY and reset PAM back to the defaults.

Don't get me wrong, it's good for security purposes, and I've seen proper implementations go off smoothly, but PAM isn't something you take lightly as an admin, nor just recklessly deploy to the masses without considering the consequences and the likelihood of seeing topics and emails about someone being locked out of root or a secondary login, or administrative user account being disabled.

To be perfectly honest with you, PAM is just one of those packages you either build around and wait for chaos to ensue, or leave as optional and have less to worry about in the long-term.

As someone who's dealt with PAM, I highly recommend against using it honestly, unless you are thoroughly prepared for the possible fallout. Besides, in reality shadow+cracklib works just as well along with other security protocols and implementations.

You really have to weigh the pros and cons of packages like PAM from the viewpoint of a distribution maintainer and also a system administrator before you consider deploying them. It's the old argument of, "If I could, would I, and if I would, should I?"

FUD?
I think all distributions that I use beside Slackware ship PAM.
I have never been locked out.
just because I did not do something equally stupid than rm -rf or was it just luck?

It's not FUD sadly. It would be nice if PAM was a software package that did have a fail-safe to prevent accidents, but it doesn't.

There are many reasons both to include and not to include it, but sadly the reasons anyone can list for not including are fairly bad such as the account lock-out issue which can actually result from anything. Plus there is the problem that if your system is compromised, someone can edit the config and totally lock you out taking over control of your system entirely. It's worst case scenario, but still it has to be considered.

1 members found this post helpful.

??
And if you don't use PAM you are somehow immune to these things?

3 members found this post helpful.

Doesn't matter if you use it or not. If your system is compromised, it's just yet another tool that a hacker can use against you.

I'm done arguing on this point as honestly it's stupid. Patrick left it out for a damned good reason, and whether or not that reason was touched on or not in this topic, remains what it is. It was left out for a damned good reason.

It is what it is, so take that in or out of context however you like. Patrick has his reasons, and in my systems, I have my own. If they aren't the same or the same doesn't matter. PAM is entirely optional to UNIX as a whole, has never been a requirement, and it's set up and implementation varies system to system for whatever purpose. If brand X distro wants to include it, then that's their baby.

He has, back in 2010.

4 members found this post helpful.

So ANYTHING can cause PAM to completely break? Obviously PAM will only break if something is done to break it. In normal configuration/usage it would do just fine. Don't blame the software for user error.
Something like the following (or a variation of it) would probably lock you out with just plain shadow (DO NOT TRY THIS AT HOME):
I don't see how this is any different than breaking PAM configuration. If someone has access to your machine and can get elevated privileges then of course they could break your installation and prevent you from logging in. What a silly argument.