Do you guys really think any significant number of enterprise users will suddenly migrate to Slackware because pam/kereberos being added when they continue to use redhat, suse and ubuntu instead? Or better yet why would this be beneficial for Slackware?

Certainly might be useful for some KDE users which I am not one, but honestly I would still consider a single KDE feature to be a niche thing.

Regardless this is not my decision, I'm just contributing to the discussion.

I wouldn't expect a mass influx of user because of any change with regard to this, no.


There's an argument for running the same code-paths that everyone else is, rather than taking the less travelled non-pam code-paths through applications which have likely been neglected for a number of years now.

7 members found this post helpful.

We've certainly been told of enterprise users who didn't choose Slackware when they could have done so due to its inability to integrate with Active Directory.

8 members found this post helpful.

Actually this is a good possibility; with the addition of Pam & Kerberos combined with a sane/stable init, Slackware becomes a compelling argument for the business world.

3 members found this post helpful.

Even if Slackware was not embraced by enterprise admins, many Slackers want to use Slackware at their jobs. PAM makes this easier.

10 members found this post helpful.

I've flip-flopped a few times on wanting PAM/Krb5 in Slackware. Certainly it would mean one fewer obstacle to acceptance in the enterprise, which is important to me personally. The argument that PAM-using code paths are better-tested by the community at large is also compelling to me, and Slackware is all about safety and stability, IMO.

On the other hand, I totally get the wariness at putting additional complexity in our packages, especially if it's complexity for features one will never use. Complexity increases risk of failure and adds overhead to troubleshooting, but in the case of PAM/Krb5 I expect these effects to be more than offset by the increased testing.

As for reverting PAM out of Slackware packages, I don't think that would be too hard. Given a list of relevant packages, rebuilding them using the pre-PAM Slackbuilds should be straightforward, at least until the distribution drifts too far for those Slackbuilds to run trouble-free. Then they would need to be maintained.

Personally I look forward to PAM coming to Slackware. It's one more task off the list of "enterprisey" features -- http://ciar.org/ttk/public/enterprise-slackware.html

11 members found this post helpful.

Or just to connect from HOME to their employers servers.

5 members found this post helpful.

Perhaps I'm late to the party here, but having worked with vbatt's PAM stuff in the past, I can vouch that PAM need not be intrusive or difficult. I am HIGHLY confident that if volkerdi does decide to include PAM (of which I am a proponent), that he will be able to craft defaults that even the most orbea's among us will not feel a negative impact beyond "I see this extra library here".

I do like how our BDFL and much of our community is skeptical about change for just the sake of change, and I think it speaks volumes that we have resisted PAM this far. But most of those early concerns about PAM have indeed been resolved.

And while inclusion of PAM may not in of itself open up the flood gates of inclusion into the enterprise space, the lack of PAM is most likely that which continues to guarantee it isn't included in the enterprise space.

If Pat does decide to include and needs some help with testing it, I can offer my time to set up a few vm's and a krb5 test domain to try to test it out.

If Pat instead decides to not include, I hope that 15.0 will be on the horizon as I'd like to be able to revisit vbatt's notes/scripts so I won't have to constantly track -current's changes.

8 members found this post helpful.

Just a technical thought, apart from having to recompile lots of packages that would be linked to PAM, how would PAM be updated?
Say a new version is needed to fix bugs/security issues, you can't just remove it and install a newer version, because when as part of upgradepkg the old binaries are removed, permissions to continue installing anything will be lost, because the PAM binary/library called by rm, cp or anything else that checks permissions to write files/directories will be missing; or am I not understanding PAM correctly?

If PAM is configured to just use /etc/shadow and /etc/passwd then the change should be unnoticeable, but if anyone changes that config, they will be on their own, as debugging PAM permissions related issues may be beyond many. Microsoft's insistence on limiting domain/ad stuff to pro or server versions of windows means I am not likely to use those extra features myself.
I do hope we will still be able to run X as root. I don't like the "root police" telling me I can't do stuff on my own systems because I might do something bad and mess them up. :-)

When's the last time you had a software issue because you were using a bitrotten code path without pam? I haven't run into that at all.

I can count those people on one hand, don't mistake being loud with being popular.

Believe or not, that's exactly why I do not believe myself in the words of those few ultras who are very vocal in this forum against PAM or whatever.

I am not a pro-PAM or anti-PAM, but, probably as many others, I see its addition also as an opportunity for Mr. Volkerding to gain some traction from the business world.

And is obvious that even a small company can cover well the financial loss resulting from that mythical "mass exodus" of those few ultras hanging on this forum...

5 members found this post helpful.

I struggle to envision Pat going down that kind of road. I don't ever recall Pat being in the business of telling or forcing people how to use their computer.

There are some misunderstandings here.

rm, cp etc do not check permissions to write files/directories, the kernel does that, and it does not use PAM for that.

For example, sshd or xdm would use PAM to authenticate. Could a new incoming ssh connection not succeed if tried at the same time as upgradepkg pam? No problem: upgradepkg does everything in the right order, so it does not first remove the old libpam.so and only then create a new one.

Even after upgrading libraries, old running processes keep using the old library and the file is really deleted from the disk only after the last process keeping it open is killed. So, a '/etc/rc.d/rc.sshd restart' could be a good idea if it were a security patch of libpam.

6 members found this post helpful.

Let me give a reverse example then. As a software packager, I have run into issues on several occasions when new software releases (often related to KDE4 or Plasma5 desktop) had no provision for running or even compiling without PAM, and discussions with the developers were needed to rectify the omission. Luckily the KDE developers are willing to support anyone who comes knocking, and as a result Plasma5 is a desktop which runs great on Slackware without any shortcuts.

PAM dependencies should - and can - be made optional, but not all software developers are open-minded enough to accept that and are willing to spend the time to write code to support a minority of users.

15 members found this post helpful.

I have a vague recollection of an issue with 'su' a few years back that only affected non-pam installs. Can't remember the details now but it had something to do with tty handling.

1 members found this post helpful.