Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pam_prompt not exported #21

Open
lmm-git opened this issue Jul 17, 2022 · 1 comment
Open

pam_prompt not exported #21

lmm-git opened this issue Jul 17, 2022 · 1 comment

Comments

@lmm-git
Copy link

lmm-git commented Jul 17, 2022

Functions like pam_prompt and pam_syslog are blocklisted in build.rs.

Is there any particular reason for that? I think when writing a pam module the function pam_prompt is the intended way to communicate with the user like when calling pam_error in C, which is currently not available with the pam-sys and therefore also with pam crates.

I saw that the initial blocking of those functions were comitted in this commit, which indicates that there is an issue with openPAM/freeBSD. Maybe it is sufficient to exclude those functions for this platform?

Furthermore, pam_error does not get exported, probably due to this rust-bindgen issue.

My current workaround is to implement functions like pam_error in the pam crate. An alternative would be to re-implement those functions as a macro in this crate, but I personally like the first method more as it is more explicit and the current structure of the pam crate does require a wrapping function anyways.

I do have patches ready for exporting pam_prompt and pam_syslog as well as using pam_prompt in your pam crate. If there is no particular reason why the functions pam_prompt and pam_syslog were excluded in the first place, I would submit these patches as PRs.

@1wilkens
Copy link
Owner

1wilkens commented Mar 2, 2023

Hey sorry for the late reply!
To be honest, I cannot completely recollect if this change was related to openPAM but I think so. We are figuring out how to properly deal with this in #18. Afterwards all functions present in the respective implementation should be available.
Regarding pam_error I am also leaning to implementing this in pam to minimize friction with bindgen.
I currently don't have a timeline for this, but would be happy to accept PRs once the "multi-implementation"-support is landed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants