[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_session bug?



On Sun, May 17, 1998 at 09:57:56AM -0700, Andrew Morgan wrote:
> Savochkin Andrey Vladimirovich writes:
> > What do people think about the following requirements:
> > 
> > 1. Requirements for modules.
> > 
> > 1.1. Modules MUST NOT expect that PAM functions of different kinds
> >      will be called from the same process. Application MAY
> >      fork() and call PAM functions of different kinds from different
> >      processes.
> > 
> >      The kinds are:
> >         - pam_authenticate()
> >         - pam_acct_mgmt() and pam_chauthtok()
> >         - pam_open_session() and pam_close_session()
> >         - pam_setcred().
> 
> This is fair.  The process that calls the function should be
> indistinguishable from the true originator, since 'pamh' is the common
> identifier and this is an opaque data type.

I want to add that my intentions were to give a permission for a code like:

	pam_handle_t the_pamh;
	...
	pam_start(&the_pamh)
	pam_authenticate(the_pamh)
	...
	if (pid=fork()) {
		/* parent */
		...
		pam_open_session(the_pamh)
		...
	}else {
		/* child */
		...
		pam_setcred(the_pamh)
		...
	}

#1 requires that module functions
  - should not assume that PID of the process will be same for calls
    of different kinds;
  - should not assume that private module data changes made in
    for instance pam_open_session() will be visible from
    pam_setcred().

Do people agree on it?

Derrick, could you explain what you expect from an application
concerning pam_setcred and pam_authenticate?

> 
> > 1.2. Modules SHOULD not make assumptions about kernel credentials
> >      and capabilities of the process for the following calls:
> >         - pam_authenticate()
> >         - pam_acct_mgmt() and pam_chauthtok()
> >         - pam_open_session() and pam_close_session().
> 
> This is not quite how I would have worded it.  How about?:

Fine. Thanks.

> 
>   1.2 Modules that require kernel credentials (user or group
>       identities and/or raised capabilities), should fail gracefully
>       when these are not available to the current (invoking) process.
> 
[snip]
> > 1.4. Module MAY assume that pam_open_session() and pam_close_session()
> >      are called in the same process and with the same kernel credentials.
>                          ^^^^^^^^^^^^
> 
> This explicitly contradicts the original RFC.  It has been our
> experience that obeyong 1.4 is the simplest way to manage sessions,
> but in general (see the normal behavior of 'init') I think we would be
> wrong to demand it.

Sorry, it's not clear for me what behavior of 'init' is spoken about.

Andrew, what do you think about my new edition?

[snip]
> > 2.1. pam_open_session() and pam_close_session() SHOULD be called
> >      in the same process and with the same kernel credentials.
> 
> See above.  It is clear, however, that something _must_ call
> pam_close_session() when pam_open_session() is called.  If the
> application does not do this, the documentation should explain how
> this is supposed to happen.  Perhaps the application should be
> accompanied by a clean-up application?

If pam_close_session() were called from the different application
how it would be possible to pass to the call the same pamh handle?


Here is the second edition of the requirements.

Andrew, if we come to an agreement is it possible to include
the document into the PAM documentation?

Best wishes
		Andrey


0. Preamble.

   In this document, the words that are used to define the
   significance of each particular requirement are capitalized.

   These words are:

   *    "MUST"

        This word or the adjective "REQUIRED" means that the item
        is an absolute requirement of the specification.

   *    "SHOULD"

        This word or the adjective "RECOMMENDED" means that there
        may exist valid reasons in particular circumstances to
        ignore this item, but the full implications should be
        understood and the case carefully weighed before choosing
        a different course.

   *    "MAY"

        This word or the adjective "OPTIONAL" means that this item
        is truly optional.

1. Requirements for modules.

1.1. Modules MUST NOT expect that PAM functions of different kinds
     will be called from the same process. Applications MUST be allowed to
     fork() and to call PAM functions of different kinds from different
     processes.

     The kinds are:
        - pam_authenticate()
        - pam_acct_mgmt() and pam_chauthtok()
        - pam_open_session() and pam_close_session()
        - pam_setcred().

1.2. Modules that require kernel credentials (user or group
     identities and/or raised capabilities), MUST fail gracefully
     when these are not available to the current (invoking) process.

     Documentation accompanied the module MUST state
     these requirements.

1.3. The documentation accompanying the module MUST mentioned
     all external resources EXPLICITLY used by the module including:
        - names of files which the module accesses;
        - if the module uses SYSV IPC;
        - if the module uses sockets;
        - which remote hosts and services the module uses if present.

1.4. A module that isn't designed to work when pam_setcred(PAM_ESTABLISH_CRED)
     and pam_setcred(PAM_DELETE_CRED) are called with the different kernel
     credentials or from different processes being not a descendant of each
     other, MUST fail gracefully if it happened.

     Module's documentation MUST state that the module will not work
     under this condition.

1.5. A module that isn't designed to work when pam_open_session() and
     pam_close_session() are called with the different kernel credentials
     or from different processes being not a descendant of each other,
     MUST fail gracefully if it happened.

     Module's documentation MUST state that the module will not work
     under this condition.

2. Requirements for applications.

2.1. pam_open_session() and pam_close_session() SHOULD be called
     with the same kernel credentials.  pam_close_session() SHOULD
     be called from the same process that pam_open_session()
     or from its descendant.

2.2. pam_setcred(PAM_ESTABLISH_CRED) and pam_setcred(PAM_DELETE_CRED)
     SHOULD be called in the same process with the same kernel credentials.
     pam_setcred(PAM_DELETE_CRED) SHOULD be called from the same process that
     pam_setcred(PAM_ESTABLISH_CRED) or from its descendant.

2.3. If the application doesn't obey 2.1 or 2.2 its documentation MUST
     emphase the fact.  It should be clear to a administrator from
     the documentation that some modules can't be plugged in the application.
     The documentation MUST state the kernel
     credentials at the moment of calls and describe how the process tree
     is organized.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []