On Monday, 21 December 2020 04:34:22 GMT Walter Dnes wrote: > On Sat, Dec 19, 2020 at 09:19:33PM -0500, John Covici wrote > > > OK, pardon my ignorance, what is wrong with pam? Aside from the fact > > that when you change versions you have to reboot or restart just about > > everything. > > It's obscure/different. That's important, because if you need to > tweak a regular config file or fix something broken, the first reaction > is to "ask Mr. Google". And you'll almost always get the non-pam > answer. In my early days with Gentoo I left the default at pam. But I > soon got sick and tired of "implementing configs" I found on Google, > only to find they didn't work. The URL I pointed to gives one such > example, sudoers. So I simply switched away from pam.
Default settings work faultlessly here, although I don't often tweak PAM configurations. > pam is one example of the corporate take-over of linux. According to > https://subscription.packtpub.com/book/networking_and_servers/9781904811329/ > 1/ch01lvl1sec06/history-of-pam pam was released in 1997, by Sun > Microsystems, who were a big player in the corporate Unix space at that > time. The rationale... it scales better... > https://subscription.packtpub.com/book/networking_and_servers/9781904811329 > /1/ch01lvl1sec08/need-for-pam Right, the "scales better" argument is not valid for a single PC user and domestic settings, but primarily PAM helps to standardize authentication mechanisms across different applications, instead of leaving it to each application developer to concoct their own hard coded authentication scheme, which may or may not be patched in a timely fashion when a vulnerability is reported. I appreciate kerberizing the login for a domestic desktop would be deemed rather unnecessary and insanely geeky, but PAM can be left in its simple vanilla config without any corporate extended authentication complexity and use shadow with its PAM plugin. PAM also integrates conveniently with keyrings. > > Furthermore, the password file does not scale. It might work with > > 100 users, but working with 5000 users is a completely different > > story. PAM can easily scale to tens of thousands depending on the > > chosen back end; changing the back end user database, for example, > > from a flat file to an LDAP server will be painful if you are not > > using PAM. > > I've got 3 users on my machine; root; me; and a > general-screwing-around-and-testing user. All of them are actually me. > pam assumes that some of the 5,000 users at corporate HQ are malicious > actors, trying to break into other users' accounts. Ditto for systemd. > I've got a NAT-ing router and a "Paranoia Plus" iptables ruleset. So > far, that's been sufficient for me. Yes, but as I understand it PAM is not only meant to control botnets knocking on your door, but also control what authenticated user/apps/conditions can or cannot do following authentication - if say they were to be inadvertently compromised. Anyway, I vote for more user choice, so fully respect the option to not have PAM on a system. > And don't get me started on the corporatization of IPV6. Heh, it certainly duplicates the workload when hacking firewall rules. ;-)
signature.asc
Description: This is a digitally signed message part.
