binary prompts and pam limited by some other protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I remember a big discussion here about binary prompts
with pam, and how that may solve problem with integrating
pam to an applications uses some protocol (like pop or
ftp) that limits pam usage.  I still can't understand
what are binary prompts and how them may solve a problem
(can someone enlighten me here?).  But I used pop daemon
(written by me) here that implements APOP command using
pam.  When APOP is enabled and daemon gets it from
client, it then sets up pam_env with it's random seed
(APOP_SEED=012345), sets up PAM_USER as usual, and
uses apop hash value as PAM_AUTHTOK when requested.
In pop's pam stack, I defined "pam_apop" module as
sufficient (first in a stack) that checks APOP_SEED
variable and verifies supplied hash if variable is
set, returning OK or AUTHFAIL, or returns PAM_IGNORE
if not set.  This isn't perfect (pam_apop must be
the first module who asks for an AUTHTOK, for example),
but it works.  The question: how this may be done with
binary prompts (if can at all -- note that at least
generation of random seed should be done at pop server
startup -- it should be shown in a first welcome line
server responds to connection attempt)?  Note that
APOP is only example here -- think of any other AUTH
in pop/imap, or even STLS/STARTTLS - should that last
one fit with pam also (STARTTLS may provide user's
certificate info)?  The question is real: if e.g.
APOP can be done with binary prompts, then there is
no need to introduce other "protocols" around pam
like APOP_SEED environment variable, but I'm afraid
that if I release my pop daemon to public as it is
now, people will start to write pop modules for it
based on wrong "pam protocol".

Thank you!

Regards,
 Michael.





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux