summaryrefslogtreecommitdiffstats
path: root/doc/man/pam_conv.3
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 14:22:51 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 14:22:51 +0000
commit9ada0093e92388590c7368600ca4e9e3e376f0d0 (patch)
treea56fe41110023676d7082028cbaa47ca4b6e6164 /doc/man/pam_conv.3
parentInitial commit. (diff)
downloadpam-9ada0093e92388590c7368600ca4e9e3e376f0d0.tar.xz
pam-9ada0093e92388590c7368600ca4e9e3e376f0d0.zip
Adding upstream version 1.5.2.upstream/1.5.2upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r--doc/man/pam_conv.3177
-rw-r--r--doc/man/pam_conv.3.xml228
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..5f65b2e
--- /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: 09/03/2021
+.\" Manual: Linux-PAM Manual
+.\" Source: Linux-PAM Manual
+.\" Language: English
+.\"
+.TH "PAM_CONV" "3" "09/03/2021" "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 &lt;security/pam_appl.h&gt;</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] = &amp; (( *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>