Yeah, good luck with that!
You'd have to recompile half the distro and you'd break the other half in the process.

1 members found this post helpful.

It doesn't matter to me either way, I have pam, cracklib and krb5 installed only to fulfill dependency requirements for Cinnamon DE so it would just mean 3 less things that I have to build. I have nothing different to do as far as logging in nor have I had any other issues, but again I am only fulfilling dependency requirements.

Can someone show where recently things have been broken or issues have arisen from having pam/krb5? I don't want to hear about 10yo problems.

I am not trying to infuriate anyone, I just want to know/see some real world issues.

That's right, it's not easy to go back once a system is built to be PAM aware.

I do have to admit that it's probably time to stop fighting this one, though. A simple, Patrick Volkerding style PAM configuration probably won't be so bad anyway. I can work with it, I just don't prefer it.

I'm also of a mind that fewer dependencies are better, especially on a packaging system that doesn't do dependency tracking (also an endearing feature of Slackware for me).

1 members found this post helpful.

You're absolutely correct that PAM has the ability to make these types of changes, but are you saying they can't be configured out of the box to the same policies and limits that we currently have with Slackware? I find that hard to believe.

I don't think this is a consideration that Pat really cares about. His goal sounds like it is to make adding PAM unnoticeable by the vast majority of users. Of course, there will be people who want to remove it (which will be really difficult, just like if anyone wanted to remove openssl, perl, python, ffmpeg, etc) and others will want to utilize the extra options it provides, but for the vast majority of users, are they going to notice the change? If so, what changes will they notice?

So, if you start mucking about files in the /etc/ folder without understanding what you're doing, you might break the system? Is that supposed to be something groundbreakingly new? Because I've messed up my system in the past by editing files in there without realizing that I was breaking something. And is repairing it really going to be much more difficult to fix compared to screwing up your /etc/passwd or /etc/shadow? I'm not asking that to prove a point, but trying to understand. I don't think it would be much more difficult, but as I said above, I'm not familiar enough with PAM to know for sure.

1 members found this post helpful.

I don't think it is. PAM may still be as architecturally ugly as ever, but it's going to be completely transparent in use if you only enable the pam_unix.so modules. I can live with it.

I guess without login policies, it wouldn't be. Think recovering from a lost or maliciously changed root password, or otherwise corrupted password hash for one example. Right now you can just boot with a rescue disk and blank out root from /etc/shadow like this:

Then reboot and use the passwd command to set a new one. With PAM policies comes more complexity to circumvent.

I guess also, if single user mode is configured to log in with no password, it would also be a non issue.

Can you not chroot the environment like now after booting off the install media and run passwd to change root's password? It's not like the system is encrypted when using PAM. Is there precautions that PAM implements to prevent something like that from happening?

I wouldn't know about Microsoft Networking, but central authentication on 100 % Linux systems needs this stuff too. For the record, I asked for these features a few years back, but only managed to cause a few raised eyebrows among the ultras.

Cheers,

Niki

Yes, that's what you'd have to do. Boot up with install media, manually chroot (not boot with e.g. "root=/dev/sd?? noinitrd" as then that would use the system's login) and run passwd.

My method would not work with PAM policies in place, you'd have to edit that configuration too.

It was just an example off the top of my head. I'm generally in favour of keeping things as simple as possible. Let's say something happened to delete those files, it's pretty easy to recreate /etc/passwd and shadow based on distro default files, with blank hashes then use passwd to fix user logins.

But whatever, I'll manage with whatever Slackware does with this.

1 members found this post helpful.

Which is basically the same type of thing someone would need to do if they forgot to run lilo after upgrading a kernel. But so far, it seems all your "changes" are just issues when something goes wrong or someone screws up the system, but day to day for most users, it should be about the same, right?

Basically, but also someone that might run afoul of PAM policies that isn't used to them. Again, we don't know how it's going to be configured yet so we don't know, but for another example PAM policies prevent users starting X as root on some distros. PAM policies can prevent things like blank or weak passwords too.

I've used PAM based systems for many years. I seldom pay much mind other than to disable a module here and there, such as motd. In a PAM based system /etc/shadow is still used. Recovering a PAM based system is no different than recovering a Slackware.

PAM in Slackware will be a nice step toward acceptance in the enterprise. Some home users might not care but many users will.

Besides, this is Pat's distro. He'll do as he pleases. We're simply along for the ride.

6 members found this post helpful.

Again, you're talking potential configuration issues, but Pat has already stated his intention is to have people "not even notice it's there", so it is extremely unlikely he is going to enable any of these different policies/modules by default. You then stated it will change the way we do things, but the only examples you seem to give are when things are broken by the user or if Pat enables some of the modules that change how logins work.

With your posts, I think you've cemented the fact that Pat should be able to include PAM with the changes likely going unnoticed by anyone not reading the changelog.

Yes, if someone manages to enable some of the modules or jacks up their login info, it might be a slightly different process to fix it, but how rarely do people screw up their ability to log in? I don't know if I've ever done it in my 15+ years of using Linux (and I was a huge n00b when I first started), but it's probably happened at least a few times. But considering the potential fix might be easier than when people forget to run lilo (since they'll have to bind mount several directories), it seems like the fix is still relatively simple.

1 members found this post helpful.

Well, my main point is simply that this is not a change to be taken lightly (and I do trust that it isn't being taken lightly). It's a major change to Slackware. Sure, I have to agree that people that don't change anything probably won't notice if there are no policies that change existing system behaviour.

Dinosaur, here

I am sorry if some of my discussion posts are inappropriate in their respective threads. I just realized I've been doing that here. This thread was started by people who are enquiring about the change, and are eager to test it.

2 members found this post helpful.