Started this, but couldn't get a simple PAM test application to work. Someone with
more PAM experience (not necessarily from a coding point of view) please step up to
help me.
Changes
tags Milestone-0.6
MattJ
on
Pushing back to 0.7. Again, someone who is familiar with PAM would be appreciated :)
Changes
tagsMilestone-0.6 Milestone-0.7
MattJ
on
This can be closed by the new Cyrus SASL patch which is pending review/integration
and due for for 0.7.
Changes
tags Status-Started
torsten.raudssus
on
Native PAM is required, ticket stays open <smile>
Native support is important to stay independent of anything around. Many people would
like to have a specific structure which probably not involve a Cyrus SASL (beside
that I personally had only totally bad experiences with Cyrus SASL). Also it is
important for being simple.
MattJ
on
Removing the 0.7 milestone on this (0.7 is overdue), will be considered for 0.8.
Changes
tagsMilestone-0.7
normanr
on
What about supporting jabberd2's pipe-auth [1], it's pretty basic, you spawn a
subprocess on start, and send it username & base64 encoded password, and it returns OK
or NO. Shelling out to a subprocess also means only the subprocess that checks
passwords has grp:shadow and not the entire daemon.
[1] http://www.cpan.org/authors/id/N/NJ/NJH/jabberd-authpipe-pam-0.1.pl
Doesn't seem to me like native PAM is important, I've been happily doing PAM auth via Cyrus for months now. Maybe some documentation is in order?
MattJ
on
Unfortunately the complexity of Cyrus SASL is more than I would like to recommend to the vast number of people who already use PAM for other things. The documentation does mention that PAM is supported by Cyrus SASL, but if you see something specific that could be improved let me know.
In the meantime a native PAM backend is certainly on the todo list, but not high priority.
I see you have been working on this. Any news regarding merging my new version in its entirety?
Dennis Schridde
on
mod_auth_pam in current prosody-modules is still broken and unusable. The version attached here almost two years ago is still an improvement to the current version, compatible to current Prosody 0.10. Is there any reason why it has not yet been merged? Does it need improvement in any way?
Zash
on
Every time I test, mod_auth_pam in current prosody-modules is working just fine, provided its dependencies are installed. I also helped someone the other day with it and it turned out to only be missing dependencies, then it worked fine. Is there a more detailed motivation than "t's broken and unusable"?
Support for authentication via PAM
Started this, but couldn't get a simple PAM test application to work. Someone with more PAM experience (not necessarily from a coding point of view) please step up to help me.
ChangesPushing back to 0.7. Again, someone who is familiar with PAM would be appreciated :)
ChangesMilestone-0.6Milestone-0.7This can be closed by the new Cyrus SASL patch which is pending review/integration and due for for 0.7.
ChangesNative PAM is required, ticket stays open <smile> Native support is important to stay independent of anything around. Many people would like to have a specific structure which probably not involve a Cyrus SASL (beside that I personally had only totally bad experiences with Cyrus SASL). Also it is important for being simple.
Removing the 0.7 milestone on this (0.7 is overdue), will be considered for 0.8.
ChangesMilestone-0.7What about supporting jabberd2's pipe-auth [1], it's pretty basic, you spawn a subprocess on start, and send it username & base64 encoded password, and it returns OK or NO. Shelling out to a subprocess also means only the subprocess that checks passwords has grp:shadow and not the entire daemon. [1] http://www.cpan.org/authors/id/N/NJ/NJH/jabberd-authpipe-pam-0.1.pl
forgot the very simple example flow (password encoding is base64): http://codex.xiaoka.com/svn/jabberd2/trunk/docs/dev/c2s-pipe-authenticator
Doesn't seem to me like native PAM is important, I've been happily doing PAM auth via Cyrus for months now. Maybe some documentation is in order?
Unfortunately the complexity of Cyrus SASL is more than I would like to recommend to the vast number of people who already use PAM for other things. The documentation does mention that PAM is supported by Cyrus SASL, but if you see something specific that could be improved let me know. In the meantime a native PAM backend is certainly on the todo list, but not high priority.
I am using attached authentication module to handle PAM. It uses my lua-pam [1] Lua module. [1] https://github.com/devurandom/lua-pam
AttachmentsI see you have been working on this. Any news regarding merging my new version in its entirety?
mod_auth_pam in current prosody-modules is still broken and unusable. The version attached here almost two years ago is still an improvement to the current version, compatible to current Prosody 0.10. Is there any reason why it has not yet been merged? Does it need improvement in any way?
Every time I test, mod_auth_pam in current prosody-modules is working just fine, provided its dependencies are installed. I also helped someone the other day with it and it turned out to only be missing dependencies, then it worked fine. Is there a more detailed motivation than "t's broken and unusable"?