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_open/close_session
, these functions will get a
better write up once I appreciate them 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?
resp_retcode
of struct pam_message
, has no
purpose at the moment. Ideas/suggestions welcome!
conv()
the response should be copied
to some allocated memory. This will ensure that no static variables
etc. in the application cause problems when used repeatedly!