1
Open-PAM working group ## A.G. Morgan
2
Internet Draft: ## Dec 8, 2001
3
Document: draft-morgan-pam-08.txt ##
4
Expires: June 8, 2002 ##
5
Obsoletes: draft-morgan-pam-07.txt##
7
## Pluggable Authentication Modules (PAM) ##
11
This document is a draft specification. Its contents are subject to
12
change with revision. The latest version of this draft may be obtained
15
http://www.kernel.org/pub/linux/libs/pam/pre/doc/
19
Linux-PAM-'version'-docs.tar.gz
21
It is also contained in the Linux-PAM tar ball.
25
This document is concerned with the definition of a general
26
infrastructure for module based authentication. The infrastructure is
27
named Pluggable Authentication Modules (PAM for short).
31
Computers are tools. They provide services to people and other
32
computers (collectively we shall call these _users_ entities). In
33
order to provide convenient, reliable and individual service to
34
different entities, it is common for entities to be labelled. Having
35
defined a label as referring to a some specific entity, the label is
36
used for the purpose of protecting and allocating data resources.
38
All modern operating systems have a notion of labelled entities and
39
all modern operating systems face a common problem: how to
40
authenticate the association of a predefined label with applicant
43
There are as many authentication methods as one might care to count.
44
None of them are perfect and none of them are invulnerable. In
45
general, any given authentication method becomes weaker over time. It
46
is common then for new authentication methods to be developed in
47
response to newly discovered weaknesses in the old authentication
50
The problem with inventing new authentication methods is the fact that
51
old applications do not support them. This contributes to an inertia
52
that discourages the overhaul of weakly protected systems. Another
53
problem is that individuals (people) are frequently powerless to layer
54
the protective authentication around their systems. They are forced
55
to rely on single (lowest common denominator) authentication schemes
56
even in situations where this is far from appropriate.
58
PAM, as discussed in this document, is a generalization of the
59
approach first introduced in [#$R#{OSF_RFC_PAM}]. In short, it is a
60
general framework of interfaces that abstract the process of
61
authentication. With PAM, a service provider can custom protect
62
individual services to the level that they deem is appropriate.
64
PAM has nothing explicit to say about transport layer encryption.
65
Within the context of this document encryption and/or compression of
66
data exchanges are application specific (strictly between client and
67
server) and orthogonal to the process of authentication.
71
Here we pose the authentication problem as one of configuring defined
72
interfaces between two entities.
74
#$$#{players} Players in the authentication process
76
PAM reserves the following words to specify unique entities in the
77
authentication process:
80
the entity (user) initiating an application for service
81
[PAM associates the PAM_RUSER _item_ with this requesting user].
84
the entity (user) under whose identity the service application
85
is negotiated and with whose authority service is granted.
88
the entity (user) whose identity is being authenticated
89
[PAM associates the PAM_USER _item_ with this identity].
92
the application that provides service, or acts as an
93
authenticated gateway to the requested service. This
94
application is completely responsible for the server end of
95
the transport layer connecting the server to the client.
96
PAM makes no assumptions about how data is encapsulated for
97
exchanges between the server and the client, only that full
98
octet sequences can be freely exchanged without corruption.
101
application providing the direct/primary interface to
102
applicant. This application is completely responsible
103
for the client end of the transport layer connecting the
104
server to the client. PAM makes no assumptions about how data
105
is encapsulated for exchanges between the server and the
106
client, only that full octet sequences can be freely
107
exchanged without corruption.
110
authentication binary that provides server-side support for
111
some (arbitrary) authentication method.
114
authentication binary that provides client-side support for
115
some (arbitrary) authentication method.
117
Here is a diagram to help orient the reader:
119
## +-------+ +--------+ ##
120
## . . . . .| agent | .| module | ##
121
## . +-------+ .+--------+ ##
124
## +---------+ +-------+ . +------+ ##
125
## | | |libpamc| . |libpam| ##
126
## | | +-------+ . +------+ ##
127
## |applicant| | . | ##
128
## | | +--------+ +----------+ ##
129
## | |---| client |-----------| server | ##
130
## +---------+ +--------+ +----------+ ##
132
Solid lines connecting the boxes represent two-way interaction. The
133
dotted-directed lines indicate an optional connection beteween the
134
plugin module (agent) and the server (applicant). In the case of the
135
module, this represents the module invoking the 'conversation'
136
callback function provided to libpam by the server application when it
137
inititializes the libpam library. In the case of the agent, this may
138
be some out-of-PAM API interaction (for example directly displaying a
141
#$$ Defined Data Types
143
In this draft, we define two composite data types, the text string and
144
the binary prompt. They are the data types used to communicate
145
authentication requests and responses.
147
#$$$#{text_string} text string
149
The text string is a simple sequence of non-NUL (NUL = 0x00)
150
octets. Terminated with a single NUL (0x00) octet. The character set
151
employed in the octet sequence may be negotiated out of band, but
154
## --------------------------- ##
155
## [ character data | NUL ] ##
156
## [ octet sequence | 0x00 ] ##
157
## --------------------------- ##
159
Within the rest of this text, PAM text strings are delimited with a
160
pair of double quotes. Example, "this" = {'t';'h';'i';'s';0x00}.
162
#$$$#{binary_prompt} binary prompt
164
A binary prompt consists of a stream of octets arranged as follows:
166
## ---------------------------------------- ##
167
## [ u32 | u8 | (length-5 octets) ] ##
168
## [ length | control | data ] ##
169
## ---------------------------------------- ##
171
That is, a 32-bit unsigned integer in network byte order, a single
172
unsigned byte of control information and a sequence of octets of
173
length (length-5). The composition of the _data_ is context dependent
174
but is generally not a concern for either the server or the client. It
175
is very much the concern of modules and agents.
177
For purposes of interoperability, we define the following control
180
## value symbol description ##
181
## ------------------------------------------------- ##
182
## 0x01 PAM_BPC_OK - continuation packet ##
183
## 0x02 PAM_BPC_SELECT - initialization packet ##
184
## 0x03 PAM_BPC_DONE - termination packet ##
185
## 0x04 PAM_BPC_FAIL - unable to execute ##
187
The following control characters are only legal for exchanges between
188
an agent and a client (it is the responsibility of the client to
189
enforce this rule in the face of a rogue server):
191
## 0x41 PAM_BPC_GETENV - obtain client env.var ##
192
## 0x42 PAM_BPC_PUTENV - set client env.var ##
193
## 0x43 PAM_BPC_TEXT - display message ##
194
## 0x44 PAM_BPC_ERROR - display error message ##
195
## 0x45 PAM_BPC_PROMPT - echo'd text prompt ##
196
## 0x46 PAM_BPC_PASS - non-echo'd text prompt ##
197
## 0x46 PAM_BPC_STATUS - ping all active clients##
198
## 0x47 PAM_BPC_ABORT - please abort session ##
200
Note, length is always equal to the total length of the binary
201
prompt and represented by a network ordered unsigned 32 bit integer.
203
#$$$$#{agent_ids} PAM_BPC_SELECT binary prompts
205
Binary prompts of control type PAM_BPC_SELECT have a defined
206
data part. It is composed of three elements:
210
The agent_id is a sequence of characters satisfying the following
213
/^[a-z0-9\_]+(@[a-z0-9\_.]+)?$/
215
and has a specific form for each independent agent.
217
o Agent_ids that do not contain an at-sign (@) are to be considered as
218
representing some authentication mode that is a "public
219
standard" see reference [#$R#{PAM_STD_AGENTIDS}]. Registered names
220
MUST NOT contain an at-sign (@).
222
o Anyone can define additional agents by using names in the format
223
name@domainname, e.g. "ouragent@example.com". The part following
224
the at-sign MUST be a valid fully qualified internet domain name
225
[RFC-1034] controlled by the person or organization defining the
226
name. (Said another way, if you control the email address that
227
your agent has as an identifier, they you are entitled to use
228
this identifier.) It is up to each domain how it manages its local
231
The '/' character is a mandatory delimiter, indicating the end of the
232
agent_id. The trailing data is of a format specific to the agent with
238
In a previous section (#{players}) we identified the most general
239
selection of authentication participants. In the case of network
240
authentication, it is straightforward to ascribe identities to the
241
defined participants. However, there are also special (less general)
242
cases that we recognize here.
244
The primary authentication step, when a user is directly introduced
245
into a computer system (log's on to a workstation) is a special case.
246
In this situation, the client and the server are generally one
247
application. Before authenticating such a user, the applicant is
248
formally unknown: PAM_RUSER is NULL.
250
Some client-server implementations (telnet for example) provide
251
effective full tty connections. In these cases, the four simple text
252
string prompting cases (see below) can be handled as in the primary
253
login step. In other words, the server absorbs most of the overhead of
254
propagating authentication messages. In these cases, there needs to be
255
special client/server support for handling binary prompts.
257
In some circumstances, a legacy network transfer protocol can carry
258
authentication information. In such cases, a desire to support legacy
259
clients (with no client-side support for PAM) will neccessitate the
260
'hardcoding' of an agent protocol into the server application. Whilst
261
against the spirit of PAM, this special casing can be managed by the
262
server's 'conversation function' (see below). The guiding principle
263
when implementing such support is for the application developer to
264
relegate the authentication process to the PAM module -- simply
265
performing a transcription of data from binary-prompt to legacy
266
network 'packet' and visa-versa for propagating replies back to the
267
driving PAM module. A common case of this is with network protocols
268
that define an initialization packet of "user+password". In such cases
269
one should attempt to support the "userpass" agent-id and its defined
272
#$ Defined interfaces for information flow
274
Here, we discuss the information exchange interfaces between the
275
players in the authentication process. It should be understood that
276
the server side is responsible for driving the authentication of the
277
applicant. Notably, every request received by the client from the
278
server must be matched with a single response from the client to the
281
#$$#{applicant_client} Applicant <-> client
283
Once the client is invoked, requests to the applicant entity are
284
initiated by the client application. General clients are able to make
285
the following requests directly to an applicant:
288
echo error text string
289
prompt with text string for echo'd text string input
290
prompt with text string for concealed text string input
292
the nature of the interface provided by the client for the benefit of
293
the applicant entity is client specific and not defined by PAM.
295
#$$#{client_agent} Client <-> agent
297
In general, authentication schemes require more modes of exchange than
298
the four defined in the previous section (#{applicant_client}). This
299
provides a role for client-loadable agents. The client and agent
300
exchange binary-messages that can have one of the following forms:
303
binary prompt agent expecting binary prompt reply to client
306
binary prompt reply from agent to clients binary prompt
308
Following the acceptance of a binary prompt by the agent, the agent
309
may attempt to exchange information with the client before returning
310
its binary prompt reply. Permitted exchanges are binary prompts of the
314
set environment variable (A)
315
get environment variable (B)
317
echo error text string (D)
318
prompt for echo'd text string input (E)
319
prompt for concealed text string input (F)
321
In response to these prompts, the client must legitimately respond
322
with a corresponding binary prompt reply. We list a complete set of
323
example exchanges, including each type of legitimate response (passes
326
## Type | Agent request | Client response ##
327
## --------------------------------------------------------------- ##
328
## (A) | {13;PAM_BPC_PUTENV;"FOO=BAR"} | {5;PAM_BPC_OK;} ##
329
## | {10;PAM_BPC_PUTENV;"FOO="} | {5;PAM_BPC_OK;} ##
330
## | {9;PAM_BPC_PUTENV;"FOO"} (*) | {5;PAM_BPC_OK;} ##
331
## | {9;PAM_BPC_PUTENV;"BAR"} (*) | {5;PAM_BPC_FAIL;} ##
332
## --------------------------------------------------------------- ##
333
## (B) | {10;PAM_BPC_GETENV;"TERM"} | {11;PAM_BPC_OK;"vt100"} ##
334
## | {9;PAM_BPC_GETENV;"FOO"} | {5;PAM_BPC_FAIL;} ##
335
## --------------------------------------------------------------- ##
336
## (C) | {12;PAM_BPC_TEXT;"hello!"} | {5;PAM_BPC_OK;} ##
337
## | {12;PAM_BPC_TEXT;"hello!"} | {5;PAM_BPC_FAIL;} ##
338
## --------------------------------------------------------------- ##
339
## (D) | {11;PAM_BPC_ERROR;"ouch!"} | {5;PAM_BPC_OK;} ##
340
## | {11;PAM_BPC_ERROR;"ouch!"} | {5;PAM_BPC_FAIL;} ##
341
## --------------------------------------------------------------- ##
342
## (E) | {13;PAM_BPC_PROMPT;"login: "} | {9;PAM_BPC_OK;"joe"} ##
343
## | {13;PAM_BPC_PROMPT;"login: "} | {6;PAM_BPC_OK;""} ##
344
## | {13;PAM_BPC_PROMPT;"login: "} | {5;PAM_BPC_FAIL;} ##
345
## --------------------------------------------------------------- ##
346
## (F) | {16;PAM_BPC_PASS;"password: "} | {9;PAM_BPC_OK;"XYZ"} ##
347
## | {16;PAM_BPC_PASS;"password: "} | {6;PAM_BPC_OK;""} ##
348
## | {16;PAM_BPC_PASS;"password: "} | {5;PAM_BPC_FAIL;} ##
350
(*) Used to attempt the removal of a pre-existing environment
353
#$$ Client <-> server
355
Once the client has established a connection with the server (the
356
nature of the transport protocol is not specified by PAM), the server
357
is responsible for driving the authentication process.
359
General servers can request the following from the client:
361
(to be forwarded by the client to the applicant)
363
echo error text string
364
prompt for echo'd text string response
365
prompt for concealed text string response
367
(to be forwarded by the client to the appropriate agent)
368
binary prompt for a binary prompt response
370
Client side agents are required to process binary prompts. The
371
agents' binary prompt responses are returned to the server.
373
#$$ Server <-> module
375
Modules drive the authentication process. The server provides a
376
conversation function with which it encapsulates module-generated
377
requests and exchanges them with the client. Every message sent by a
378
module should be acknowledged.
380
General conversation functions can support the following five
381
conversation requests:
385
prompt for echo'd text string response
386
prompt for concealed text string response
387
binary prompt for binary prompt response
389
The server is responsible for redirecting these requests to the
392
#$ C API for application interfaces (client and server)
394
#$$ Applicant <-> client
396
No API is defined for this interface. The interface is considered to
397
be specific to the client application. Example applications include
398
terminal login, (X)windows login, machine file transfer applications.
400
All that is important is that the client application is able to
401
present the applicant with textual output and to receive textual
402
input from the applicant. The forms of textual exchange are listed
403
in an earlier section (#{applicant_client}). Other methods of
404
data input/output are better suited to being handled via an
405
authentication agent.
409
The client makes use of a general API for communicating with
410
agents. The client is not required to communicate directly with
411
available agents, instead a layer of abstraction (in the form of a
412
library: libpamc) takes care of loading and maintaining communication
413
with all requested agents. This layer of abstraction will choose which
414
agents to interact with based on the content of binary prompts it
415
receives that have the control type PAM_BPC_SELECT.
417
#$$$ Client <-> libpamc
419
#$$$$ Compilation information
421
The C-header file provided for client-agent abstraction is included
422
with the following source line:
424
\#include <security/pam_client.h>
426
The library providing the corresponding client-agent abstraction
427
functions is, libpamc.
431
#$$$$ Initializing libpamc
433
The libpamc library is initialized with a call to the following
436
pamc_handle_t pamc_start(void);
438
This function is responsible for configuring the library and
439
registering the location of available agents. The location of the
440
available agents on the system is implementation specific.
442
pamc_start() function returns NULL on failure. Otherwise, the return
443
value is a pointer to an opaque data type which provides a handle to
444
the libpamc library. On systems where threading is available, the
445
libpamc libraray is thread safe provided a single (pamc_handler_t *)
446
is used by each thread.
448
#$$$$ Client (Applicant) selection of agents
450
For the purpose of applicant and client review of available agents,
451
the following function is provided.
453
char **pamc_list_agents(pamc_handle_t pch);
455
This returns a list of pointers to the agent_id's of the agents which
456
are available on the system. The list is terminated by a NULL pointer.
457
It is the clients responsibility to free this memory area by calling
458
free() on each agent id and the block of agent_id pointers in the
461
PAM represents a server-driven authentication model, so by default
462
any available agent may be invoked in the authentication process.
464
#$$$$$ Client demands agent
466
If the client requires that a specific authentication agent is
467
satisfied during the authentication process, then the client should
468
call the following function, immediately after obtaining a
469
pamc_handle_t from pamc_start().
471
int pamc_load(pamc_handle_t pch, const char *agent_id);
473
agent_id is a PAM text string (see section #{agent_ids}) and is not
474
suffixed with a '/' delimiter. The return value for this function is:
476
PAM_BPC_TRUE - agent located and loaded.
477
PAM_BPC_FALSE - agent is not available.
479
Note, although the agent is loaded, no data is fed to it. The agent's
480
opportunity to inform the client that it does not trust the server is
481
when the agent is shutdown.
483
#$$$$$ Client marks agent as unusable
485
The applicant might prefer that a named agent is marked as not
486
available. To do this, the client would invoke the following function
487
immediately after obtaining a pamc_handle_t from pam_start().
489
int pamc_disable(pamc_handle_t pch, const char *agent_id);
491
here agent_id is a PAM text string containing an agent_id (section
494
The return value for this function is:
496
PAM_BPC_TRUE - agent is disabled. This is the response
497
independent of whether the agent is locally
500
PAM_BPC_FALSE - agent cannot be disabled (this may be because
501
it has already been invoked).
503
#$$$$ Allocating and manipulating binary prompts
505
All conversation between an client and an agent takes place with
506
respect to binary prompts. A binary prompt (see section #{binary_prompt}), is
507
obtained, resized and deleted via the following C-macro:
509
CREATION of a binary prompt with control X1 and data length Y1:
511
pamc_bp_t prompt = NULL;
512
PAM_BP_RENEW(&prompt, X1, Y1);
514
REPLACEMENT of a binary prompt with a control X2 and data length Y2:
516
PAM_BP_RENEW(&prompt, X2, Y2);
518
DELETION of a binary prompt (the referenced prompt is scrubbed):
520
PAM_BP_RENEW(&prompt, 0, 0);
522
Note, the PAM_BP_RENEW macro always overwrites any prompt that you
523
call it with, deleting and liberating the old contents in a secure
524
fashion. Also note that PAM_BP_RENEW, when returning a prompt of data
525
size Y1>0, will always append a '\0' byte to the end of the prompt (at
526
data offset Y1). It is thus, by definition, acceptable to treat the
527
data contents of a binary packet as a text string (see #{text_string}).
529
FILLING a binary prompt from a memory pointer U1 from offset O1 of
532
PAM_BP_FILL(prompt, O1, L1, U1);
534
the CONTROL type for the packet can be obtained as follows:
536
control = PAM_PB_CONTROL(prompt);
538
the LENGTH of a data within the prompt (_excluding_ its header
539
information) can be obtained as follows:
541
length = PAM_BP_LENGTH(prompt);
543
the total SIZE of the prompt (_including_ its header information)
544
can be obtained as follows:
546
size = PAM_BP_SIZE(prompt);
548
EXTRACTING data from a binary prompt from offset O2 of length L2 to
551
PAM_BP_EXTRACT(prompt, O2, L2, U2);
553
If you require direct access to the raw prompt DATA, you should use
556
__u8 *raw_data = PAM_BP_DATA(prompt);
558
#$$$$ Client<->agent conversations
560
All exchanges of binary prompts with agents are handled with the
563
int pamc_converse(pamc_handle_t *pch, pamc_bp_t *prompt_p);
565
The return value for pamc_converse(...) is PAM_BPC_TRUE when there is
566
a response packet and PAM_BPC_FALSE when the client is unable to
567
handle the request represented by the original prompt. In this latter
568
case, *prompt_p is set to NULL.
570
This function takes a binary prompt and returns a replacement binary
571
prompt that is either a request from an agent to be acted upon by the
572
client or the 'result' which should be forwarded to the server. In the
573
former case, the following macro will return 1 (PAM_BPC_TRUE) and in
574
all other cases, 0 (PAM_BPC_FALSE):
576
PAM_BPC_FOR_CLIENT(/* pamc_bp_t */ prompt)
578
Note, all non-NULL binary prompts returned by pamc_converse(...), are
579
terminated with a '\0', even when the full length of the prompt (as
580
returned by the agent) does not contain this delimiter. This is a
581
defined property of the PAM_BP_RENEW macro, and can be relied upon.
583
Important security note: in certain implementations, agents are
584
implemented by executable binaries, which are transparently loaded and
585
managed by the PAM client library. To ensure there is never a leakage
586
of elevated privilege to an unprivileged agent, the client application
587
should go to some effort to lower its level of privilege. It remains
588
the responsibility of the applicant and the client to ensure that it
589
is not compromised by a rogue agent.
591
#$$$$ Status of agents
593
int pamc_status(pamc_handle_t *pch, pamc_bp_t *prompt_p);
595
At any time, the client may ping all active agents for their status
596
(with a PAM_BPC_STATUS binary prompt). If any agent replies with
597
PAM_BPC_ABORT, the client is responsible for terminating the
598
connection to the server and then terminating all agents with a call
599
to pamc_end(). In such cases, the return value of pamc_status() is
602
If the return status of pamc_status() is PAM_BPC_TRUE and *prompt_p is
603
non-NULL, then an agent is requesting access to a server module.
605
XXX - how this information gets propagated to the server, and
606
ultimately to the server's module is yet to be determined.
608
#$$$$ Termination of agents
610
When closing the authentication session and severing the connection
611
between a client and a selection of agents, the following function is
614
int pamc_end(pamc_handle_t *pch);
616
Following a call to pamc_end, the pamc_handle_t will be invalid.
618
The return value for this function is one of the following:
620
PAM_BPC_TRUE - all invoked agents are content with
621
authentication (the server is _not_ judged
622
_un_trustworthy by any agent)
624
PAM_BPC_FALSE - one or more agents were unsatisfied at
625
being terminated. In general, the client
626
should terminate its connection to the
627
server and indicate to the applicant that
628
the server is untrusted.
630
#$$$ libpamc <-> agents
632
The agents are manipulated from within libpamc. Each agent is an
633
executable in its own right. This permits the agent to have access to
634
sensitive data not accessible directly from the client. The mode of
635
communication between libpamc and an agent is through a pair of
636
pipes. The agent reads binary prompts (section #{binary_prompt})
637
through its standard input file descriptor and writes response (to the
638
server) binary prompts and instruction binary prompts (instructions
639
for the client) through its standard output file descriptor.
641
#$$ Client <-> server
643
This interface is concerned with the exchange of text and binary
644
prompts between the client application and the server application. No
645
API is provided for this as it is considered specific to the transport
646
protocol shared by the client and the server.
648
#$$ Server <-> modules
650
The server makes use of a general API for communicating with
651
modules. The client is not required to communicate directly with
652
available modules. By abstracting the authentication interface, it
653
becomes possible for the local administrator to make a run time
654
decision about the authentication method adopted by the server.
656
#$$$ Functions and definitions available to servers and modules
658
[This section will document the following functions
662
pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec)
663
pam_get_env(pam_handle_t *pamh, const char *varname)
664
pam_strerror(pam_handle_t *pamh, int pam_errno)
666
Event driven support (XXX work in progress)
668
pam_register_event() - app or module associates an event poller/handler
669
pam_select_event() - query for any outstanding event and act on any
672
#$$$ Server <-> libpam
674
[This section will document the following pam_ calls:
685
The asterisked functions may return PAM_INCOMPLETE. In such cases, the
686
application should be aware that the conversation function was called
687
and that it returned PAM_CONV_AGAIN to a module. The correct action
688
for the application to take in response to receiving PAM_INCOMPLETE,
689
is to acquire the replies so that the next time the conversation
690
function is called it will be able to provide the desired
691
responses. And then recall pam_authenticate (pam_chauthtok) with the
692
same arguments. Libpam will arrange that the module stack is resumed
693
from the module that returned before. This functionality is required
694
for programs whose user interface is maintained by an event loop. ]
696
#$$$ libpam <-> modules
698
[This section will document the following pam_ and pam_sm_ calls:
700
functions provided by libpam
705
functions provided to libpam by each module
716
AUTHENTICATION TOKEN MANAGEMENT
720
#$$$ The conversation function
722
The server application, as part of its initialization of libpam,
723
provides a conversation function for use by modules and libpam. The
724
purpose of the conversation function is to enable direct communication
725
to the applicant ultimately via the client and selected agents.
727
[ this section will contain a definition for the conversation
728
function, the conversation structure (appdata etc), and legitimate
729
return codes for the application supplied function.
731
PAM_SUCCESS - ok conversation completed
732
PAM_CONV_ERR - conversation failed
733
PAM_CONV_AGAIN - application needs control to complete conv
734
PAM_CONV_RECONSIDER - application believes module should check if
735
it still needs to converse for this info
738
#$ Security considerations
740
This document is devoted to standardizing authentication
741
infrastructure: everything in this document has implications for
746
The email list for discussing issues related to this document is
747
<pam-list@redhat.com>.
751
[#{OSF_RFC_PAM}] OSF RFC 86.0, "Unified Login with Pluggable Authentication
752
Modules (PAM)", October 1995
754
[#{PAM_STD_AGENTIDS}] Definitions for standard agents, "REGISTERED
755
AGENTS AND THEIR AGENT-ID'S", to be found here:
757
## http://www.kernel.org/pub/linux/libs/pam/pre/doc/std-agent-ids.txt ##
762
Email: morgan@kernel.org
764
## $Id: draft-morgan-pam.raw,v 1.1.1.2 2002/09/15 20:08:34 hartmans Exp $ ##
added
removed
Linux-PAM/doc/specs/draft-morgan-pam.raw
