diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 12:01:37 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 12:01:37 +0000 |
commit | de848d9e9146434817c65d74d1d0313e9d729462 (patch) | |
tree | dcbd0efb229b17f696f7195671f05b354b4f70fc /doc/man/pam_conv.3 | |
parent | Initial commit. (diff) | |
download | pam-de848d9e9146434817c65d74d1d0313e9d729462.tar.xz pam-de848d9e9146434817c65d74d1d0313e9d729462.zip |
Adding upstream version 1.4.0.upstream/1.4.0upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r-- | doc/man/pam_conv.3 | 177 | ||||
-rw-r--r-- | doc/man/pam_conv.3.xml | 228 |
2 files changed, 405 insertions, 0 deletions
diff --git a/doc/man/pam_conv.3 b/doc/man/pam_conv.3 new file mode 100644 index 0000000..181604e --- /dev/null +++ b/doc/man/pam_conv.3 @@ -0,0 +1,177 @@ +'\" t +.\" Title: pam_conv +.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author] +.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/> +.\" Date: 06/08/2020 +.\" Manual: Linux-PAM Manual +.\" Source: Linux-PAM Manual +.\" Language: English +.\" +.TH "PAM_CONV" "3" "06/08/2020" "Linux-PAM Manual" "Linux-PAM Manual" +.\" ----------------------------------------------------------------- +.\" * Define some portability stuff +.\" ----------------------------------------------------------------- +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.\" http://bugs.debian.org/507673 +.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" ----------------------------------------------------------------- +.\" * set default formatting +.\" ----------------------------------------------------------------- +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.\" ----------------------------------------------------------------- +.\" * MAIN CONTENT STARTS HERE * +.\" ----------------------------------------------------------------- +.SH "NAME" +pam_conv \- PAM conversation function +.SH "SYNOPSIS" +.sp +.ft B +.nf +#include <security/pam_appl\&.h> +.fi +.ft +.sp +.nf +struct pam_message { + int msg_style; + const char *msg; +}; + +struct pam_response { + char *resp; + int resp_retcode; +}; + +struct pam_conv { + int (*conv)(int num_msg, const struct pam_message **msg, + struct pam_response **resp, void *appdata_ptr); + void *appdata_ptr; +}; + +.fi +.SH "DESCRIPTION" +.PP +The PAM library uses an application\-defined callback to allow a direct communication between a loaded module and the application\&. This callback is specified by the +\fIstruct pam_conv\fR +passed to +\fBpam_start\fR(3) +at the start of the transaction\&. +.PP +When a module calls the referenced conv() function, the argument +\fIappdata_ptr\fR +is set to the second element of this structure\&. +.PP +The other arguments of a call to conv() concern the information exchanged by module and application\&. That is to say, +\fInum_msg\fR +holds the length of the array of pointers, +\fImsg\fR\&. After a successful return, the pointer +\fIresp\fR +points to an array of pam_response structures, holding the application supplied text\&. The +\fIresp_retcode\fR +member of this struct is unused and should be set to zero\&. It is the caller\*(Aqs responsibility to release both, this array and the responses themselves, using +\fBfree\fR(3)\&. Note, +\fI*resp\fR +is a +\fIstruct pam_response\fR +array and not an array of pointers\&. +.PP +The number of responses is always equal to the +\fInum_msg\fR +conversation function argument\&. This does require that the response array is +\fBfree\fR(3)\*(Aqd after every call to the conversation function\&. The index of the responses corresponds directly to the prompt index in the pam_message array\&. +.PP +On failure, the conversation function should release any resources it has allocated, and return one of the predefined PAM error codes\&. +.PP +Each message can have one of four types, specified by the +\fImsg_style\fR +member of +\fIstruct pam_message\fR: +.PP +PAM_PROMPT_ECHO_OFF +.RS 4 +Obtain a string without echoing any text\&. +.RE +.PP +PAM_PROMPT_ECHO_ON +.RS 4 +Obtain a string whilst echoing text\&. +.RE +.PP +PAM_ERROR_MSG +.RS 4 +Display an error message\&. +.RE +.PP +PAM_TEXT_INFO +.RS 4 +Display some text\&. +.RE +.PP +The point of having an array of messages is that it becomes possible to pass a number of things to the application in a single call from the module\&. It can also be convenient for the application that related things come at once: a windows based application can then present a single form with many messages/prompts on at once\&. +.PP +In passing, it is worth noting that there is a discrepancy between the way Linux\-PAM handles the const struct pam_message **msg conversation function argument and the way that Solaris\*(Aq PAM (and derivatives, known to include HP/UX, are there others?) does\&. Linux\-PAM interprets the msg argument as entirely equivalent to the following prototype const struct pam_message *msg[] (which, in spirit, is consistent with the commonly used prototypes for argv argument to the familiar main() function: char **argv; and char *argv[])\&. Said another way Linux\-PAM interprets the msg argument as a pointer to an array of num_msg read only \*(Aqstruct pam_message\*(Aq pointers\&. Solaris\*(Aq PAM implementation interprets this argument as a pointer to a pointer to an array of num_msg pam_message structures\&. Fortunately, perhaps, for most module/application developers when num_msg has a value of one these two definitions are entirely equivalent\&. Unfortunately, casually raising this number to two has led to unanticipated compatibility problems\&. +.PP +For what its worth the two known module writer work\-arounds for trying to maintain source level compatibility with both PAM implementations are: +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +never call the conversation function with num_msg greater than one\&. +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +set up msg as doubly referenced so both types of conversation function can find the messages\&. That is, make +.sp +.if n \{\ +.RS 4 +.\} +.nf + msg[n] = & (( *msg )[n]) + +.fi +.if n \{\ +.RE +.\} +.RE +.SH "RETURN VALUES" +.PP +PAM_BUF_ERR +.RS 4 +Memory buffer error\&. +.RE +.PP +PAM_CONV_ERR +.RS 4 +Conversation failure\&. The application should not set +\fI*resp\fR\&. +.RE +.PP +PAM_SUCCESS +.RS 4 +Success\&. +.RE +.SH "SEE ALSO" +.PP +\fBpam_start\fR(3), +\fBpam_set_item\fR(3), +\fBpam_get_item\fR(3), +\fBpam_strerror\fR(3), +\fBpam\fR(8) diff --git a/doc/man/pam_conv.3.xml b/doc/man/pam_conv.3.xml new file mode 100644 index 0000000..5106ddf --- /dev/null +++ b/doc/man/pam_conv.3.xml @@ -0,0 +1,228 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> +<refentry id='pam_conv'> + <refmeta> + <refentrytitle>pam_conv</refentrytitle> + <manvolnum>3</manvolnum> + <refmiscinfo class='setdesc'>Linux-PAM Manual</refmiscinfo> + </refmeta> + + <refnamediv id="pam_conv-name"> + <refname>pam_conv</refname> + <refpurpose>PAM conversation function</refpurpose> + </refnamediv> + +<!-- body begins here --> + + <refsynopsisdiv> + <funcsynopsis id="pam_conv-synopsis"> + <funcsynopsisinfo>#include <security/pam_appl.h></funcsynopsisinfo> + </funcsynopsis> + <programlisting> +struct pam_message { + int msg_style; + const char *msg; +}; + +struct pam_response { + char *resp; + int resp_retcode; +}; + +struct pam_conv { + int (*conv)(int num_msg, const struct pam_message **msg, + struct pam_response **resp, void *appdata_ptr); + void *appdata_ptr; +}; + </programlisting> + </refsynopsisdiv> + + <refsect1 id='pam_conv-description'> + <title>DESCRIPTION</title> + <para> + The PAM library uses an application-defined callback to allow + a direct communication between a loaded module and the application. + This callback is specified by the + <emphasis>struct pam_conv</emphasis> passed to + <citerefentry> + <refentrytitle>pam_start</refentrytitle><manvolnum>3</manvolnum> + </citerefentry> + at the start of the transaction. + </para> + <para> + When a module calls the referenced conv() function, the argument + <emphasis>appdata_ptr</emphasis> is set to the second element of + this structure. + </para> + <para> + The other arguments of a call to conv() concern the information + exchanged by module and application. That is to say, + <emphasis>num_msg</emphasis> holds the length of the array of + pointers, <emphasis>msg</emphasis>. After a successful return, the + pointer <emphasis>resp</emphasis> points to an array of pam_response + structures, holding the application supplied text. The + <emphasis>resp_retcode</emphasis> member of this struct is unused and + should be set to zero. It is the caller's responsibility to release + both, this array and the responses themselves, using + <citerefentry> + <refentrytitle>free</refentrytitle><manvolnum>3</manvolnum> + </citerefentry>. Note, <emphasis>*resp</emphasis> is a + <emphasis>struct pam_response</emphasis> array and not an array of + pointers. + </para> + <para> + The number of responses is always equal to the + <emphasis>num_msg</emphasis> conversation function argument. + This does require that the response array is + <citerefentry> + <refentrytitle>free</refentrytitle><manvolnum>3</manvolnum> + </citerefentry>'d after + every call to the conversation function. The index of the + responses corresponds directly to the prompt index in the + pam_message array. + </para> + <para> + On failure, the conversation function should release any resources + it has allocated, and return one of the predefined PAM error codes. + </para> + <para> + Each message can have one of four types, specified by the + <emphasis>msg_style</emphasis> member of + <emphasis>struct pam_message</emphasis>: + </para> + <variablelist> + <varlistentry> + <term>PAM_PROMPT_ECHO_OFF</term> + <listitem> + <para> + Obtain a string without echoing any text. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>PAM_PROMPT_ECHO_ON</term> + <listitem> + <para> + Obtain a string whilst echoing text. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>PAM_ERROR_MSG</term> + <listitem> + <para> + Display an error message. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>PAM_TEXT_INFO</term> + <listitem> + <para> + Display some text. + </para> + </listitem> + </varlistentry> + </variablelist> + <para> + The point of having an array of messages is that it becomes possible + to pass a number of things to the application in a single call from + the module. It can also be convenient for the application that related + things come at once: a windows based application can then present a + single form with many messages/prompts on at once. + </para> + <para> + In passing, it is worth noting that there is a discrepancy between + the way Linux-PAM handles the const struct pam_message **msg + conversation function argument and the way that Solaris' PAM + (and derivatives, known to include HP/UX, are there others?) does. + Linux-PAM interprets the msg argument as entirely equivalent to the + following prototype + const struct pam_message *msg[] (which, in spirit, is consistent with + the commonly used prototypes for argv argument to the familiar main() + function: char **argv; and char *argv[]). Said another way Linux-PAM + interprets the msg argument as a pointer to an array of num_msg read + only 'struct pam_message' pointers. Solaris' PAM implementation + interprets this argument as a pointer to a pointer to an array of + num_msg pam_message structures. Fortunately, perhaps, for most + module/application developers when num_msg has a value of one these + two definitions are entirely equivalent. Unfortunately, casually + raising this number to two has led to unanticipated compatibility + problems. + </para> + <para> + For what its worth the two known module writer work-arounds for trying + to maintain source level compatibility with both PAM implementations + are: + </para> + <itemizedlist> + <listitem> + <para> + never call the conversation function with num_msg greater than one. + </para> + </listitem> + <listitem> + <para> + set up msg as doubly referenced so both types of conversation + function can find the messages. That is, make + </para> + <programlisting> + msg[n] = & (( *msg )[n]) + </programlisting> + </listitem> + </itemizedlist> + </refsect1> + + <refsect1 id="pam_conv-return_values"> + <title>RETURN VALUES</title> + <variablelist> + <varlistentry> + <term>PAM_BUF_ERR</term> + <listitem> + <para> + Memory buffer error. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>PAM_CONV_ERR</term> + <listitem> + <para> + Conversation failure. The application should not set + <emphasis>*resp</emphasis>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>PAM_SUCCESS</term> + <listitem> + <para> + Success. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1 id='pam_conv-see_also'> + <title>SEE ALSO</title> + <para> + <citerefentry> + <refentrytitle>pam_start</refentrytitle><manvolnum>3</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>pam_set_item</refentrytitle><manvolnum>3</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>pam_get_item</refentrytitle><manvolnum>3</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>pam_strerror</refentrytitle><manvolnum>3</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum> + </citerefentry> + </para> + </refsect1> +</refentry> |