Hi Erin, thanks for the feedback!
> Whatever such a protocol ends up looking like, I think “you could replace > pam_systemd_home with a generic UserDB PAM module and said generic protocol” > is an important criterion Yep. Please note that I am specifically targeting the PAM auth call (and probably password changing later). Session management is sufficiently covered already, and is out of scope of this draft. > > > I would like to propose an addition to make it support authentication as > > well. The additions to the io.systemd.UserDatabase Varlink interface > > are: > > > I don’t think there’s any strict necessity for it to be in the > io.systemd.UserDatabase > Interface. In many ways I think it would be better for any such methods in a > separate > interface (because it means when you get an > `org.varlink.service.InterfaceNotFound` error > back for a given userdb service you know you can just skip all advanced > functionality > For that service for the rest of the authentication sequence) I agree. It should be a separate interface, and I propose io.systemd.UserAuth. > So a minor thing here: If you’re doing conversation tokens, I would be > inclined to make them a string and exchange it at each step, so stateless > applications can be supported. I'd rather stick with integers, but to cover your proposal (which seems very legit), I would allow passing the `variables` array back and forth at each step (see below). > > But I’m not sure if (for the auth step in particular, which is very much > driven by the module) it would be better to use sd_varlink_push_fd to send > a file descriptor across for a “reversed” varlink socket that the other end > can use to drive the PAM conversation. A nice advantage here is that you also > get automatic resource release by just closing the file descriptor. For all I know about PAM, keeping things simple for the PAM module is a better approach due to its architecture and data handling. > As described the interface proposed diverges a bunch from how > pam_sm_authenticate > and the conversation function work. As much as I dislike PAM, I don’t think > you > can get away form it; it's the lingua franca of Unix authentication after > all. Can you point out some details? I know it diverges, but I am confident it should translate quite well. > I think trying to fit OAuth token flows into “normal” PAM like this is > probably > more trouble than its worth. If you’re looking to do things beyond the basic > text > messages and prompts that PAM understands then I think we need to look > towards GDM’s > extensions [2]. They’re definitely imperfect but they’re the closest thing we > have to > a “modern” login extension to PAM right now. I am not particularly interested in actively joining GNOME's efforts, but like above, I don't think this protocol here contradicts anything they do. GNOME's approach is already handled mostly out-of-band, and a userdbd authentication service can jsut as well call GDM's D-Bus interfaces while signalling to the PAM client that it needs to get back later when it has more information. > Anything that slots in at this extension point likely needs the ability to > see any > PAM environment variables (perhaps you pass them across by calling > pam_getenvlist first) > and likely set its own; and also the ability to (when feasible) return a > token in > the PAM_AUTHTOK item that e.g. can be used to establish disk encryption or > Kerberos > credentials (where appropriate/separate from the UserDB backend) The above protocol handles that (the `variables` parameter is supposed to carry PAM environment variables). I will add it to all calls, and also to all return types so variables can be communicated bidirectionally. I actually overlooked that the service could actually set an authentication token instead of just receiving one, and will add that as well. > I don’t see a need to return the user record here. To figure out which > service you need > to call to authenticate you already need to be in possession of it. Maybe. But is conceivable that a User Record is not available before authentication, e.g. because a web backend only allows access to user information after a user token was acquired. In that case, a userdbd auth service would receive the user record after authentication (maybe in the OIDC id token), and add it to its local cache right then. > The multiplexer is completely uninvolved in login today (besides very > indirectly > i.e. through the nss_systemd compatibility shim). I don’t think this logic > belongs > in there. It belongs in whichever PAM module talks directly to the user DB. Arguable, but valid, imho. > I agree about fallback to traditional behaviour on MethodNotImplemented > > Actually I think for the pam_acct extension point there’s a good > argument > for a backend being able to return a value which means “I have no > objections > - do lockout condition validation on the record as normal" Good point. Regards, Nik
signature.asc
Description: PGP signature
