You're not the only one in this thread who has argued against PAM on the basis that it adds complexity, but I honestly have to say that in my opinion, there's hardly a component in a Unix-based system for which that argument is less valid.

PAM is a small set of library files, which live in their own subdirectory called "security" in /usr/lib[64]. There also tends to be one configuration file for each system/executable using PAM, and these reside in /etc/pam.d. Each file is very small, typically less than 20 lines, and the syntax is exceedingly simple.

That's all.

PAM configuration files are usually included with the package containing the program using PAM. The configuration file for one program does not affect those belonging to other programs. Also, having PAM on a system does in no way affect applications or daemons not using PAM; such applications will continue to work exactly as before.

I don't see how a system component could possibly be less complex. If this really is difficult for some users to handle, where were the protests when components like udev, dbus, ConsoleKit and NetworkManager were added to Slackware?

By all means, there could be many valid reasons why one might not want to include PAM in Slackware, but I don't see how "complexity" could possibly be one of them.

2 members found this post helpful.

Right here, in this Forum, my friend. Right here!

If I'm remember right, specially in the UDEV case, there was bloody riots, with epically "protest" threads, full of name calling and similar nice things, which make the today S-word threads to be more like a elevate academic polemic about "the effects of bees migration in the Bonobo's demographic"...

There was time, when in this forum, if someone suggested an improvement of Slackware, was enough for a bunch of bullies to assault with dozens of "posts" against. Was something like: "How you dare to question the pure perfection of the divine ordered Slackware?"

Luckily, the spirits much calmed down, right now, but yet there we have some reminiscences of the old bullies really fanatical thinking. For example, you known people who repeat, and repeat, and repeat, and repeat, the same "imaginary" arguments against S-word? Or PAM? Or whatever addition to Slackware?

Yeah, a happy story both for the kids and for us, and our Management, who have a new toy to sell, but, in the same time, I believe that that story demonstrate the Slackware inability to sell even in a very moderate Enterprise/Public environment, like those primary schools, under almost minimal requirements (like to offer a desktop with Open/Libre Office, Firefox and iTALC, nothing more, even no LDAP credentials), because of lack of PAM.

And, my personal regret is, that those kids grown as OpenSuSE users, instead to become some little slackers...

Thanks for link, also we, we have a similar solution for autologin, but in this case, was preferred KDM way, as in easy to configure by teachers, too...

I see. I guess this is par for the course, then.

The inclusion of udev happened before I joined the forum, but I might do a quick search to see what the arguments were. For instance, I wonder if anybody were against udev on the basis that it's a rather intrusive component and a Red Hat project, and that we would be at the mercy of Red Hat should they ever decide to cancel or radically alter the project's course. Which pretty much describes the situation we are in today.
The problem is people on both sides failing to present rational arguments, preferring instead to label the other side as "fanatics" or, as you say, repeat (mostly) empty arguments ad nauseum.

As for PAM, one argument against it could be its intrusiveness. Once adopted, one cannot simply uninstall it without breaking applications, as compiling a program with PAM support will usually introduce a hard dependency.

Now, I would lay the blame for that squarely at the feet of the developers, as there's really no reason why "use PAM" shouldn't be a configuration setting as well as a ./configure flag. For instance, the OpenSSH sshd daemon has a "UsePAM [yes|no]" setting in /etc/ssh/sshd_config, which makes it possible to deactivate PAM usage at runtime.

It should be possible to run the same executable on both PAM-enabled and PAM-less systems, but unfortunately that's often not the case. Hence, for those who absolutely do not want to use PAM, this becomes an argument against including it at all.

Actually it is the only argument that is still valid to some extent. In the early days the security was the main argument against PAM. The famous PatV's quote "PAM == SCAM" was a valid point some 15 years ago.

We can't blame developers for not providing a state of the art support for PAM-less systems. Why should they do it. Only a few Slackware-like distros don't have PAM and they are irrelevant from a developer's point of view.

Cheers

There's always embedded systems. They are usually PAM-less.

IMHO, if the application can be compiled with the "--without-pam" option, it shouldn't be too hard to include a runtime configuration option. After all, support for non-PAM environments has to be there already. But yes, it would mean some extra work just to support an extremely marginal edge case.

Also the embedded Linux systems have a very different design from a classic Linux. Typically, they are a BusyBox thing running on top of Linux kernel. Similar as idea to what we have in our Slackware initrd.

Even Android, practically is a BusyBox based mini-Linux, with a framebuffer based Destkop Environment running on top. In other hand, Android do NOT use PAM, but the Android permissions are hundred times more complex than what offer PAM.

To not be sure. To make that thing to work, you (as programmer) should use a plugin system, and to load the right API at runtime. While maybe look very nice for a Slackware user, to avoid PAMification, in reality, this plugin based work introduce a suplementary complication on your code, also, to not mind that loading plugins at runtime will be time consuming. Trust me, you do not want a Linux where everything is plugin based...

Re: udev At the time, there were complaints about udev being binaries, as opposed to the shell scripts used by hotplug. And, the syntax used to configure udev was complained about -and is still being complained about. I wasn't paying attention before or there was no forum back when hotplug was introduced, as opposed to using static device nodes, but I have no doubt there was a big stink about that. The *kits were roundly cursed here for a long time, as was kernel 2.6 and later dbus. The PAM debate seems to be like a trademark thing for some around here.

2 members found this post helpful.

I don't. That's the point I'm making, and I'm surprised it's taking you all so long to get it. Here in rural Ireland there's almost no chance of even getting a Linux or BSD admin. All the IT guys around here look at me sideways whenever I mention either Linux or BSD. They're Windows guys.
PAM might not be complex, but it is another layer of complexity, which is not the same as saying it is complex of itself. Does Niki live in a city where Linux admins are two a penny? I certainly don't, and that's why I keep the small networks I administer (<50 clients, <5 servers) as simple as possible. With the documentation I leave in place it should be easy for a decent Windows admin to come along and take up the reins if I fall under a bus. Because there is zero chance of anyone from Dublin coming out here to these rural businesses and helping them out when they can get ten times the money in Dublin for a lot less.

And no, I can't replace the servers with Windows servers, because these businesses don't have the money to pay the Microsoft tax.

1 members found this post helpful.

Look, I haven't argued against PAM. I am simply asking Niki if he really needs it. I could be wrong but I get the impression he is a sole trader without an IT team behind him. I am simply asking him if the networks he maintains justify the added complexity of PAM. That is not to say PAM is complex, but adding PAM is adding another layer that an admin with little Linux or Unix knowledge has to deal with if he is suddenly commandeered to look after a network he knows nothing about. Perhaps in big urban areas this is not a big issue. In rural Ireland it is. I am simply asking Niki if he can justify PAM in the networks he maintains. I know nothing about the area he lives in, and how many Linux admins there are in that area. If like me he lives in a rural area with Linux admins few and far between then in my opinion it might be better to KISS. That is just my opinion and it is not an argument against the inclusion of PAM in Slackware.

What complexity the inclusion of PAM will bring to you. It'll be completely transparent in your use case. You don't have to use LDAP if you don't need it.

Cheers

If Linux admins are hard to come by in his area, he should install PAM immediately. Adhering to the KISS principle under such circumstances would mean making sure the setup is as generic as possible.

Chance of finding a decent Linux admin in a remote region: Slim

Chance of finding a decent Linux admin in a remote region who knows how to adapt installation instructions to a non-PAM environment, or knows what to do when the application s/he's trying to install complains of a missing PAM library: Next to none

If you're going to continue using the term "complexity" in relation to PAM, would you mind explaining what it is about PAM you find is adding complexity to a setup? Because as I said in my previous message, I really have no idea what you could possibly be referring to. Honestly.

Since PAM has been included with nearly every distribution, enterprise or not, for many years now, anyone being hired as a Linux administrator would certainly be expected to know how to use PAM already. Otherwise they would be a Slackware/CRUX specialist and that is probably not the best person you want to hire for the job...

The point is, if you *do* need central authentication, implementing it *without* PAM is way more complex and less secure than just using the industry standard that any administrator worth their salt should already be familiar with. So this extra "layer of complexity" of PAM in this circumstance is absolutely backwards; any non-PAM central authentication system will be more home-grown than standardized and it will take future admins *more* time to decipher it upon starting the job.

For single-user desktop systems without a need for central authentication or alternative methods of authentication, then yes, PAM is more complex in that there is *some* configuration where there isn't any at all with shadow. (Of course, by default PAM should be pre-configured for these users already so there shouldn't be any problems.)

OK I'll try again.

The inclusion of PAM in Slackware would add no complexity for me. It would add a layer of complexity for the average admin coming after me. Understood now?

Perhaps the admins out there in Quebec are all like you, but here in rural Ireland they're not, so I have no intention of adding layers to the servers I manage where these layers are not needed. It would mean yet another headache for a person coming after me, a headache I would be imposing on them for no good reason. What I am asking Niki is, is this extra burden really required in the networks he manages? He is threatening to leave Slackware for CentOS over this one issue, but he knows as well as I do that what he gains on the one hand with a so-called enterprise operating system he loses on the other. Outdated software, limited scope for movement, dependency on the whim of a so-called enterprise team. Slackware allows you a lot more freedom than CentOS. I've plenty of experience with Scientific Linux, which is a nice enough system, but I don't like the restrictions a so-called enterprise OS imposes. I vastly prefer Slack, Crux and NetBSD, and I think Niki does too, if he takes time to think about it.