[dale_glass]

> Huh? You can never isolate the client side code. You will always have something in your app.

Yes, and that "something" can be reduced to reads and writes to a socket.

> So, write a module that talks to a socket. That's how like half of the PAM modules already operate.

I mean move all of PAM to a service. So for instance currently chsh is a setuid application because it needs to be able to write to /etc/passwd. This is a requirement because the way it works is that it links to libpam, which will load a module, which will write to /etc/passwd, all inside the 'chsh' program.

My suggestion would result in chsh becoming a completely unprivileged application that only deals with interfacing with the user, then passes the action to pamd, which would run with the required privileges.

[throwaway09223]

"Yes, and that "something" can be reduced to reads and writes to a socket."

Yes, and as I said that is already what most PAM modules do. That is how most things work today.

"I mean move all of PAM to a service."

I think you don't understand what PAM is.

"which will load a module, which will write to /etc/passwd"

No, this isn't how PAM works at all. PAM modules don't write to /etc/password. They just authenticate. They do not (necessarily) need root privileges.

"My suggestion would result in chsh becoming a completely unprivileged application that only deals with interfacing with the user, then passes the action to pamd, which would run with the required privileges. "

You have the way PAM and chsh works entirely backwards. Here's how it actually works:

1) chsh runs as root only because chsh itself needs to modify system files. This has nothing to do with PAM, and is optional (see below)

2) chsh calls pam_auth("chsh",...) to authenticate the current user, if the current user isn't really root. This is PAM's ONLY involvement.

3) chsh then directly edits /etc/passwd itself[1]. Totally unrelated to PAM. If you're on a system with directory services instead of local files, then chsh needs to change those directory services instead (and, as such, doesn't need to run as root - though it will need to authenticate to the directory service)

In summary, your ideas aren't bad - it's just that they're how things already work. Most PAM modules are already just talking to a socket somewhere. They don't do the other things you seem to think they do.

[1] https://github.com/mmalecki/util-linux/blob/master/login-uti...

[yrro]

For completeness it's worth mentioning that chsh calls into pam with pam_acct_mgmt and pam_open_session/pam_close_session after it's authenticated the user with pam_auth.