So make a good point as to WHY it should be included if it's such grandiose a software package that we "have to have it" on some shape, form, or level because what Patrick said in 2010 was what I said in BOLD text above. It's not a required dependency!

Even if it is 'user error' at some level, a package that adds lots of opportunities for critical breakage that were not there before probably does deserve some of the blame.

The difficulty and likelihood of it happening would seem the main difference.

From my point of view, PAM adds unnecessary complexity and lots of attack surfaces. Do you have complex attack surfaces without PAM? Very likely. Still makes sense to avoid as much of it as you can.

Yes, and because an ongoing trend in Slackware is to avoid unnecessary packages such as entirely optional dependencies when possible, I highly doubt PAM will ever become a required package to have. No software across the UNIX spectrum even requires it at all.

The complexity of PAM makes it problematic by it's very nature. Look at the packages in BLFS that require a PAM setup if PAM is compiled in and built against if and when you have time. The amount of setup required is often near monotonous levels, plus the fact that BLFS's PAM is trying to set a default that has some level of ability to work without issues and control things securely, is not even secure by nature.

Not to mention even updating PAM as a package can be extremely dangerous as well. here's an excerpt from BLFS's PAM page:

Plus the fact PAM accepts 3rd party modules makes you wonder how much control vs usability you want.

Add in the fact this guidebook:

http://www.linux-pam.org/Linux-PAM-h...x-PAM_SAG.html

Really covers a ton of information that may or may not be required, useful, or even remotely of interest to a workstation level, laptop, desktop, or server system, makes you consider the fact: do you, or do you not need PAM?

Plus there's also the problematic anyone can face that could render a system disabled as well. A file system error. Truth be told, you or anyone else can never know when or if a file system error can occur. Now granted with file systems like JFS, EXT4, ZFS, and such we might not have an issue, but then again, you never how what can happen with a kernel update. Bad code could slip through, highly unlikely, but it has happened, and a file system could get corrupted, and then what if the PAM files get knocked out?

The point is, PAM is NOT some software package that you take for granted and just willy-nilly toss it in for the sake of having it. It is software that has to be handled with care, careful planned around, and deployed safely and correctly.

Being careful with software is one thing, but being foolish with software is another.

1 members found this post helpful.

The non-inclusion of PAM is one of the reasons I'm currently switching my servers from Slackware to Ubuntu LTS. Only Bob knows how sad that makes me.

1. Centralized LDAP user authentication is not possible without PAM.
2. Some say it's possible, but this procedure is documented nowhere.
3. I'm not counting the bits of stale and/or false information, like the AOLS FAQ.
4. This leaves me with NIS, which isn't exactly state of the art security-wise, and which is very limited.

Cheers,

Niki

Edit PS: to be accurate, it *is* possible, but only by jumping through burning loops, e. g. rebuilding openldap, building Linux-PAM and then rebuild a few dozen core packages. I know Vincent Batts has a project for doing this, but this is not an option.

5 members found this post helpful.

I don't need PAM, so have no particular axe to grind, other than a general worry that the non-PAM execution paths through pkg-shadow are becoming increasingly unused, crufty, and liable to contain unidentified and unresolved issues. Remember Mancha's " Revert CVE-2005-4890 fix" needed to restore 'su -c' functionality? If I remember rightly, that issue was fixed properly in the PAM-enabled shadow, but they had to break functionality in the non-PAM shadow in order to close that potential tty hijacking issue. This may have been resolved properly by now (I've not been following shadow development very closely for a while), but its an example of the sort of thing I'm talking about here.

Clearly as Niki's post above shows, some people do need PAM features, and while its all well and good leaving it as an exercise for the user, if its absence is driving people away, then personally, I think its time to reconsider it.

7 members found this post helpful.

Yes, but that was PV 4 years ago commenting on what he thought of PAM 10 years before that.
Not exactly "current"

I'm not disputing the merit of the decision of not including PAM at the time (I'm sure the reasons were valid then), but I'd very much like to know if those reasons are still valid today.

In the IT world 4 years is a long time and PAM has been around for 14 years (and is still active)... so I expect that most of its major problems have been dealt with.

And as kikinovak said, not having a solid centralized login facility is a deal breaker in enterprise.
I use Slackware on some of my workplace servers, but can't sell it to my boss as a desktop (not just because centralized auth is missing, but that is one of the major points).

3 members found this post helpful.

Not having PAM for centralized logins shouldn't be a deal breaker for Enterprise even in Slackware's case.

To be honest, if you absolutely require PAM, you have all the tools necessary to build an on-site package repository to rebuild PAM-enabled packages using the SlackBuilds from the sources. You don't have to distribution-hop, but you shouldn't have to be hand-held either. The PAM SlackBuild is still in the 14.0/extra/source repository, you can update it on your own, track down which packages need rebuilding, and then install PAM and rebuild the required packages, so honestly you have no excuses.

In fact if you're running a server at the Enterprise level you should already be using an on-site repository with packages built to the company's IT Security Specifications anyway, not general release software.

A few years back, I went to see a friend of mine, a writer who lives in a very remote village up in the mountains in Austria. He asked me if I wanted to eat fish for dinner, and when I accepted enthusiastically, he grabbed his fishing gear, and we went to a nearby river. He's an experienced fisher, and after an hour or so, we had four big trouts in the bucket. As soon as we arrived home, he started cooking the fish, using potatoes and herbs from his garden, and the meal was delicious.

I like a similar approach for other things in life, operating systems for example. But I think that if my friend had asked me to raise some trouts first, I would politely decline and suggest we simply go to a restaurant instead. While I am a very patient person and like to experiment and fiddle a lot, I'm not the guy who builds cathedrals out of matchsticks or who crams ocean steamboats into bottles for relaxing.

Cheers,

Niki

6 members found this post helpful.

I'm not saying I'm incapable of doing so, I just wont spend my already tight schedule tracking upstream packages for updates.
If I liked doing that I'd go LFS and be done with distros altogether.
I'm a sysadmin in 2 SMBs but distro maintainer is not in the cards for me
Slackware is a tool (one of my favorites) in my tool-belt. If I can use it, I will... but I won't force a squared peg into a round hole, nor do I have the time/patience to round that peg with sand-paper

Oh, but I do
(see above)

Who told you I don't?

Those who are without patience shall have nothing whilest those with patience shall have all they need.

Slackware is a tool, yes, but it up to you the user of said tool to learn to use the tool given to you not just correctly, but within acceptable purposes. Slackware, as it is well known, is not a hand-holding distribution. It gives you a foundation regardless of how much you install, but the rest is up to you.

As a system administrator who operates a repository, you should already be developing those packages, so therein you honestly have a very flimsy excuse, even though it is one. Time is critical, but I've seen many an admin in my day wasting time on Facebook, Twitter, Tetris, etc. while they could be spending that time performing those tasks and others. If compiling all those packages is so time consuming, make time, take time, and draft a script to do all the required work while you're gone for the day, night, weekend, whatever.

Sometimes even a square peg may require sanding down to fit into a square hole as well, then again sometimes there are no square holes for your square peg. I should know. There's a nice round peg sitting in a square hole in my signature below.

ReaperX7, I'm the only one in my household who earns money, and I do this by running a small company (http://www.microlinux.fr). I know how to be organized, I don't have a television, and this year I had exactly 5 (five) days of holidays. Of course I could very well make time, stop my climbing and hiking activities, tell my girlfriend I have no time to go for a walk with her because I have to rebuild half of Slackware against Linux-PAM.

9 members found this post helpful.

I built PAM and rebuilt shadow, su, sudo and so on, in my current Slack installation back in January or something when another thread about PAM/LDAP came up. I've been authenticating against AD since then with no problems, the initial setup of everything took some research but wasn't too terrible . At this point I think the flexibility of having PAM as part of default Slack would probably be beneficial. Alternatively if anyone is considering creating some slackbuilds or something to semi-automate the process of integrating PAM and the basic packages that would need it, I'm down to help

2 members found this post helpful.

I think if I were in the situation of absolutely having to have PAM running somewhere, I would want to do it in a virtual machine, hosted on a machine without it. Perhaps I would even run corebuntu in the VM, just to save time. But I would not want it to be part of the distro I am running on the iron.

This.

Unless it's going to cause some major breakage that I'm not aware of, I think the question when it comes to including PAM should be "why not" rather than "why". The advantages of PAM are pretty obvious, and I believe the security issues that prompted PV to keep PAM out of Slackware have long since been resolved (please correct me if I'm wrong here).

8 members found this post helpful.

While I suspect the statement was tongue-in-cheek with respect to the requirement to build "half" of Slackware, I get the point about the additional overhead to include PAM in Slackware. I am curious how much change is required to include PAM in Slackware. PAM is a de facto standard package in almost all other distros. I have no opinion on that inclusion but I doubt there are serious usability problems with PAM or distro maintainers would have not included PAM as a de facto standard package. And that several Slackware users in the enterprise do PAM-ify their Slackware systems is revealing to some degree and that the exclusion of PAM requires a Slackware enthusiast active in the enterprise to choose a different distro also is revealing.

Perhaps then this thread could change focus to provide the details necessary to add PAM to Slackware? Perhaps that kind of approach would help the development team with experimenting and testing?

Also, if PAM was added to Slackware, could the defaults be to have PAM disabled such that only those who need PAM need to take active steps to enable? That is, can PAM be installed but not be used or required? Or is including PAM all-or-nothing?

3 members found this post helpful.