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

"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-utils/setpwnam.c#L27-L30 https://github.com/mmalecki/util-linux/blob/master/login-uti...