Hi Lennart, thanks for your elaborate reply (although I completely missed the big paragraph on the reasons for Varlink in the docs, making that part a stupid question on my side ;)). > Basically, a user record consist of multiple sections (i.e. json > fields contain subobjects), one is called "privileged": this contains > everything traditionally found in /etc/shadow basically, and > everything else pretty much that should only be visible to privileged > users and the user itself. > > Any IPC service is supposed to strip "privileged" from user records it > sends or passes on, and report that in the "incomplete" boolean return > parameter – unless it can know for sure (via SO_PEERCRED or so) that > whoever it is talking to is the user itself or is privileged. Ah, so what would happen here is that even if the MUltiplexer, which is privileged, talks to my IPC service and receives the "privileged" part, the Multiplexer will strip it off for me unless a privileged user is talking to it. > Yeah, you have to deal with PAM yourself (unless you add classic > hashed UNIX passwords in the "privileged" section of your use records > – in that case pam_unix will just use that). That won't work. Actually, the final goal is to authenticate without ever handling the user password, e.g. using the OIDC Authorization Code Grant Flow or Device Code Grant Flow. > Kernel keyring for the user? It's where kerberos stuff is stored, and > is probably the best place. The API is a bit convoluted, but this has > been done before. I will look into that. But generally, are the fields in the User Record objects fixed, or can I add my own fields? If I do, will they be ignored and passed on verbatim, or stripped, or cause an error preventing the User Record from being handled at all? Cheers, Nik
Attachment:
signature.asc
Description: PGP signature
