Hacker News new | ask | show | jobs
by megous 1967 days ago
su pulls in random set of currently configured PAM modules, due to requiring authentication.

Anyone checked what buggy horrors await in all those modules? And it's not a static set of old trusty modules either. The fresh new complicated stuff is being added, like systemd-homed, and so on.

pam_systemd and pam_systemd_home have by itself the size of all other 46 PAM modules combined (on my Arch system).

3 comments

Is there any part of the Linux system that systemd hasn't penetrated yet? It controls boot, processes, authentication, time, dns, proxies, etc. The GNOME Foundation unilaterally required all distros adopt Systemd ten years ago without any community support. Yocto makes it exceedingly hard to create embedded devices that don't have Systemd, so it's probably lurking on all your IoT devices.
I can't possibly see how PAM was ever considered a good idea.
I mean, it's literally in the name: Pluggable Authentication Module. It's a very good idea to expose a common interface for user authentication to hide the vagaries of the underlying authentication mechanisms.

It's far more useful to explain why or how PAM is bad, because no one (sane) will agree that the idea of PAM is bad.

Module should be implemented as a separate process running under unprivileged user and communication should be done via pipes. It's UNIX-way. If I understand it correctly, currently module is implemented as a shared library executing under root sharing all the memory with other modules and main program. This exposes way too many opportunities to exploit any vulnerability.
PAM using app can fork a process for this, so it's not too horrible, but it increases complexity.
How do you measure the sizes of these modules? I counted lines from source code and systemd pam code was a 1k-2k lines of C total and pam is 30k lines of C.
ls -l in /lib/security

I mean last time I had sshd hanging and randomly losing access to remote machines due to systemd's newest PAM improvements (homed), when I put the process under gdb, it shown dbus stuff, so it's certainly more than 1-2kloc.