Hacker News Reader

Comment by quotemstr | Hacker News Reader

PAM really needs to be ravamped and support for (among other things) running multiple stacks in par@llel added. This way you could ask for a password OR a fingerprint

View on HN

I'm vaguely considering rewriting PAM in Rust. It's definitely something that would benefit from Rust's extra security and the code quality isn't that great. Nor is the UX. What "among other things" were you thinking of?

Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.

Yeah I always thought the whole architecture of PAM being a library is weird. A sane person would have made it a Daemon that processes talk to surely?

Really it should probably be part of SystemD, but I know that would anger the anti-SystemD zealots.

> A sane person would have made it a Daemon that processes talk to surely?

> Really it should probably be part of SystemD

https://github.com/systemd/systemd/pull/39855

It's confusing how they want a custom protocol that seems to be converging from JSON-RPC, just spelled differently. They should just use JSON-RPC. In any case, it'd essential to retain PAM's customization ability even if the bulk of the work is moved out-of-process.

Not everything has to be a "daemon". It's a bad trend in current programming zeitgeist to want to make everything into one. (sccache, no, you do NOT need a daemon to behave like ccache.)

For a PAM replacement, you want a separate process. It doesn't have to be a persistent separate process.

Keypassxc does it perfectly.

Everyone doing parallel biometric and password authentication on Linux today is either running two PAM stacks in parallel (which is meta-policy that kind of defeats the purpose of PAM) or just bypassing PAM entirely.

Reply on news.ycombinator.com