> 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.
"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.
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.
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.