3 ms·

I go into more detail about this in my followup talk: https://xeiaso.net/talks/rustconf-2022-sheer-terror-pam#:~:text=So%20the%20answer%20of%20how%20you%20debug

by xena 4y ago

I go into more detail about this in my followup talk: https://xeiaso.net/talks/rustconf-2022-sheer-terror-pam#:~:text=So%20the%20answer%20of%20how%20you%20debug%20stuff%20in%20PAM%20boils%20down%20to%20%22carefully%22.%20You%20debug%20it%20carefully.%20You%20know%20what%2C%20here%27s%20a%20story%20of%20my%20first%20time%20debugging%20a%20custom%20PAM%20module https://xeiaso.net/talks/rustconf-2022-sheer-terror-pam#:~:t.... It is not easy in the slightest. PAM has aged like bottled milk in a desert.

monocasa 4y ago
Can confirm from being the maintainer of a PAM module in a past job. The only thing that was stable was debug builds that enabled awful fprintfs to a file in /tmp. It felt like how a freshman in college debugs their code.
tbrownaw 4y ago
So what's a proper way to solve the problem that PAM solves? Instead of an in-process library, have it be a daemon that responds to DBUS requests? Aside from the config language, this sounds mostly like "it's a pre-login modular C library, and that's alien territory".
- xena 4y ago
  It would probably need kernel support for this to happen, but I'd like to see a daemon in the system that runs authentication logic and then arbitrarily curses the requesting process with the UID/GID/whatever it needs to get the job done.
  - stevekemp 4y ago
    How would that work with, for example a single deamon supporting multiple (different) remote users - for example ftpd, or sshd? (I imagine you could say that sshd forks for each user, but some of the legacy systems like ftpd/ircd wouldn't have that as an option..)
- kaba0 4y ago
  I think Android has a more saner system, but I’m a layperson when it comes to these — android runs every user process under a different user that has very restricted access (restricted with SELinux as well), and they do extensive IPC. There is a daemon that handles elevated requests through IPC, so that’s where dynamic access control happens.

by xena 4y ago

monocasa 4y ago

Can confirm from being the maintainer of a PAM module in a past job. The only thing that was stable was debug builds that enabled awful fprintfs to a file in /tmp. It felt like how a freshman in college debugs their code.

tbrownaw 4y ago

So what's a proper way to solve the problem that PAM solves? Instead of an in-process library, have it be a daemon that responds to DBUS requests? Aside from the config language, this sounds mostly like "it's a pre-login modular C library, and that's alien territory".

xena 4y ago
It would probably need kernel support for this to happen, but I'd like to see a daemon in the system that runs authentication logic and then arbitrarily curses the requesting process with the UID/GID/whatever it needs to get the job done.
- stevekemp 4y ago
  How would that work with, for example a single deamon supporting multiple (different) remote users - for example ftpd, or sshd? (I imagine you could say that sshd forks for each user, but some of the legacy systems like ftpd/ircd wouldn't have that as an option..)
kaba0 4y ago
I think Android has a more saner system, but I’m a layperson when it comes to these — android runs every user process under a different user that has very restricted access (restricted with SELinux as well), and they do extensive IPC. There is a daemon that handles elevated requests through IPC, so that’s where dynamic access control happens.