Those packages that ship with Slackware and could benefit from PAM could ship with their own reasonable configs. Any additional packages that require PAM should install a reasonable default configuration, not use other. If they fall back to other and the default other conf is simply a deny, then the new service just won't be able to authenticate until its fixed. Sure a third party package could potentially ship with a broken configuration, but, well any third party package now can potentially break something too. If you don't need or use PAM now, you wouldn't have to install any such package, so you'd just be using those that ship with Slackware as you are now and relying on Pat and friend's savvy in setting up solid default configuration as you are now.

@Eloi: Living in Paris or its suburbs since, well,... 65 years, I can tell you that not all Parisian people speak English. By the way, even though he probably speaks and certainly write French better than I do, Kikinovak comes from Austria. And he lives in a remote location in southern France - as near from Paris as Granada is from Barcelona .

This remind me the old saying:
Q. How do you call someone who speaks three languages?
A. Trilingual.
Q. Two languages?
A. Bilingual.
Q. Only one language?
A. American!

Unfortunately this could apply as well to us French people.

And I know a lot of people unable to understand an English software interface in France. To tell the truth, some of them hardly understand a French software interface as well, but nonetheless that's one more hurdle on the path that lead to efficiently use a computer.

PS In my country house in "Champ de Noldrat, Saint-Martin-des-Champs, Yonne", I don't have a lawn mower either. I use a scythe only when the grass is so high that walking there becomes difficult.

PPS As our current Prime Minister, Manuel Carlos Valls Galfetti, was born in Barcelona, maybe learning Catalan will soon become mandatory in French schools

"Quand meme !"

It's not aimed at Patrick. I never said it was so please don't assume.

It's aimed at people who keep saying package-XYZ and the like need to be added to Slackware for whatever reason outside resolving dependencies and bringing about a fully working system out of the box, or the Earth will flip upside down and inside out.

You all want to add whatever to Slackware, but none of you think about the time and effort that will be added to the workload on Patrick as it is. Slackware has grown considerably since 12.x was released and that puts a lot on Patrick. Do any of you realize that maybe one of the reasons Patrick doesn't include certain packages is that either it's too time consuming for him to test, debug, and fret over needlessly, or is better handled by the community?

The end decision is going to be made by Patrick regardless, but even from my limited knowledge on Patrick, he's going to choose what's best for him to do and maybe less of a headache down the road to deal with, so if PAM makes it in, so be it, but if not, then get off your butts and build Slackbuilds on the SBo repository for PAM and PAM-enabled packages if you want it so damned bad.

I would expect people to prefer to work in their native language.

You sound like I pointed out the necessity to add cowsay, gtypist and Linux-PAM to Slackware, in that specific order.

IMHO trading KDE for PAM will solve this problem. PAM is a core system component. KDE like GNOME before it becomes unmanageable and could be better handled by the community. And once integrated PAM doesn't require so much time to maintain. Needless to say that the lack of PAM & Kerberos is a deal breaker for Slackware in the enterprise.

Cheers

Patrick won't remove KDE. It's been asked, and he said no, and if anyone asked again, the almighty wrath of Bob would be delivered upon who he shalt asketh the forbidden question.

KDE has a lot of useful tools and software packages even if you don't use the desktop itself. KWrite, for example, is an excellent text editor and script writer as it can check execution triggers and other script handlers. I use KWrite a lot when I test Runit scripts for possible syntax errors.

PAM
- your root password expired
- your root account was locked (too many failed attempts)
- the program cannot be run because the root password has expired (result was ES application crash)
- please, can you reset my password ... (result of a too often expiring password, of-course new password sent in clear-text, users starts to use stupid passwords)
- 1500 user accounts, effectively used 100 (as a result of central user account management, nobody knows whose account it is)

Only few things on my mind regrading the PAM features. Still not sure whether those theories about the so called "security features" are valid.

- expiring passwords
- account locks
- centralized account management

There are many arguments which are against these theories. But maybe this is the reason I like Slackware, cause its trying to fight against the mass-idiocy, who knows ...

And if I need something what is not included in Slackware I use another distro for that task ...

Well, you know, of course, that you don't actually need to implement password expiration or complexity policies when using PAM... right?

So, my your logic, I should not install a modern lock on the door to my house because: Do you not realize that if I don't install that other optional system, the modern lock will work just like the old one but, you know, better?

1 members found this post helpful.

Better in what way though? Newer does not always mean better, certainly not better in every way.

I'm looking at an old fashioned mechanical lock. I can *see* with my own eyes how it works. The attack surfaces are limited and relatively well known, as are the countermeasures. Then I look at the new electronic lock. I would need a microscope to begin to see how it works. It is more complicated, so there are obviously more attack surfaces, and more opportunities for failure (what happens when the power goes out? Does this thing have an IP?) Yes it potentially opens up lots of new capabilities (maybe I can have guests show up and ring the intercom and I can unlock the door and let them in with a remote, handy!) but if those new capabilities come at the cost of compromising the core mission of the lock (to make sure that I can get in and out of my home, and others cannot) they may well not be worth it.

We talk about PAM as a security package but it does not *add* security, what it adds is more ways to get through security, logically *reducing* security - which, dont get me wrong, is not necessary a bad thing. A perfectly secure system is one that's been turned off and buried in concrete. PAM adds interoperability and that's a good thing. But it comes at a cost. At the very least you have to admit it makes doing a thorough security audit a lot more complicated.

Yeah, but it is not practical, is it?
I mean, I could just wall up the door to my house, but that would lock me out as well as everyone else.
I think you missed the point my post was responding to...

I need the most secure solution possible to a problem.

PAM offers a secure way to implement a centralized authentication service (among other things) on linux.
Can you please inform me of "more secure" alternative to PAM?

2 members found this post helpful.

There's no reason why installing PAM should weaken/compromise security in any way.

First, if a piece of software does not use PAM, the old authentication scheme will work exactly as before.

Second, if a piece of software has PAM support but one chooses to disable it (OpenSSH has a UsePAM configuration setting), the old authentication sceme will be used, and it will work exactly as before.

Third, if a piece of software uses PAM for authentication, it calls one or more PAM modules to perform authentication. The number and type of modules used is entirely at the discretion of the system administrator. You can stick with PAM_UNIX if you like, and everything will work exactly as it did before.

The whole point of PAM is to modularize the authentication process and make it much more flexible. As others have mentioned, the main point is to add flexibility to the authentication and authorization process, so that one may authenticate against a large number of different account databases.

Rather than having different teams of programmers implement, say, Kerberos authentication in several different packages, it's implemented once as a PAM module. And once somebody has written an LDAP/Kerberos/winbind/RADIUS/TACACS/whatever PAM module, support for that user database can magically appear in any PAM-capable package.

Centralized account management is a must in any enterprise environment. Slackware does not currently offer this (but it's fairly easy to add).

8 members found this post helpful.

What he said

BTW, currently I work with Kate, on a "little" project with, let see... 1547 files, all opened right now. Yet, I use only the default shipped plugins, nothing else.