@jdstrand Both of these solutions present the same main problem: we’d need to offer the application inside the snap a libpam alternative that satisfies the exact ABI used when the application was compiled, forever, including any changes any distribution may have made. Distributions might already diverge today in ways that makes this impossible, but if we can pull it at all it would be a time bomb.
@till.kamppeter That approach looks more promising, but it’s still a bit tricky to pull off, because as far as can see the modules of libpam are shared libraries which get loaded into libpam’s process space, and almost certainly need direct access to its memory to work instead of being just a functional API. That implies we’re back to the same underlying issue, depending on the internal stability of libpam itself.
We may need to split the problem in two halves: a PAM module that is shipped inside the snap itself, and that communicates with snapd over a socket that offers a guaranteed-stable protocol inside the snap. snapd then takes the request and authenticates with the system itself, ending up in the system PAM modules.
If we do a good job on the PAM module that forwards the authentication request, we can submit this to the upstream project.
Coming back to the problem at hand in this topic, I suggest starting with something simple so we’re not blocked on that problem. We might just implement an interface that offers access to the passwd and shadow files of the system, and put that under tight control so it’s not generally exposed except in well known cases.