5 ms·
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. No
by timhh 2mo ago
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?
- quotemstr 2mo agoImplementation 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.
- timhh 2mo agoYeah 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.
- NekkoDroid 2mo ago> 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 https://github.com/systemd/systemd/pull/39855
- quotemstr 2mo agoIt'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.
- quotemstr 2mo agoNot 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.