I intend to put development comments here... like ``at the moment this isn't actually supported''. At release time what ever is in this section will be placed in the Bugs section below! :)
pam_status
argument of pam_end()
is passed to
cleanup()
? This seems dangerously close to making applications
module specific...? Perhaps someone can clarify this for me? Is
there going to be a recognized list of valid pam_status arguments? I
guess it should be in <security/pam_appl.h>?
pam_strerror()
should be internationalized....
pam_setcred
, this function will get a better write up
once I appreciate it better!
pam_conv
.. This seems to be a good way for the module to
set application environment variables etc. from the module . Might I
suggest that (see rfc86.0 pp26-27) we have a special action for the
conv function when the num_msg
argument is negative. For
example, if num_mesg==PAM_EXPORT_ENV( = -1 )
, then the msg
pointer points at an array of two pam_message
structures holding
the name of the environment variable and its value. While we are at it
the *resp
pointer can be directed at a pam_response holding the
previous value of this variable (or NULL
). Thoughts?
another thing that we might think about is multiple responses from
an application, I have inserted it into the code and documented it
here in the hope that no-one objects too strongly. My motivation is
simply that it seems desirable to get username and password with a
single call to conv()
. Wouldn't this be easier for windows based
applications to do logging in type things?
resp_retcode
of struct pam_message
, has no
purpose at the moment. Ideas/suggestions welcome!
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter