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

Re: pam_session bug?



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.

> 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?:

  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.

> 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.
> 
>      If a module needs particular kernel credentials or capabilities to work
>      (for example, the credentials of the superuser) the documentation
>      MUST explicitly state it.
> 
> 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.

> 1.5. Module MAY assume that pam_setcred(PAM_ESTABLISH_CRED) and
>      pam_setcred(PAM_DELETE_CRED) are called in the same process and with kernel
>      credentials of the user under whose identity the service will be granted,
>      i.e. the user whose name is set in PAM_USER item.
> 
> 1.6. If the module will not function if either 1.4 or 1.5
>      isn't satisfied this fact MUST be explicitly stated in the documentation
>      accompanying the module.
> 
> 2. Requirements for applications.
> 
> 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?

> 2.2. pam_setcred(PAM_ESTABLISH_CRED) and pam_setcred(PAM_DELETE_CRED)
>      SHOULD be called in the same process and with kernel credentials
>      of the user under whose identity the service will be granted,
>      i.e. the user whose name is set in PAM_USER item.
> 
> 2.3. If the application doesn't obey 2.1 or 2.2 rules its
>      documentation and manual pages MUST emphase it.
>      It should be clear to a administrator from the documentation that
>      some modules can't be plugged in the application.

So those are my thoughts..

Cheers

Andrew



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