SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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.
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.
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.
Originally Posted by ReaperX7
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.
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.
Last edited by Ser Olmy; 07-15-2014 at 12:03 PM.
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?"
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.
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.
That was true perhaps a decade ago, around the time I made the now infamous comment about "PAM == SCAM". Back then, many applications either had to be patched to add PAM support, or if they had PAM support it probably needed additional patches to work right. These days, the opposite is just as likely to be true. Especially with things such as ConsoleKit and polkit (which we pretty much have to include in order to provide a functional desktop), we are finding that the non-PAM code is not as well tested, and that we've had to patch things in order to work with the traditional shadow based authentication. Eventually these developments are likely to force our hand with regard to PAM (but not in the immediate future).
... the account lock-out issue which can actually result from anything.
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.
Originally Posted by ReaperX7
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.
Something like the following (or a variation of it) would probably lock you out with just plain shadow (DO NOT TRY THIS AT HOME):
# sed -i 's/^\([^:]*:\)\([^:]\+\)\(:.*\)/\1!\3/' /etc/shadow
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.