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

Re: pam_session bug?



Andrew,

On Thu, May 07, 1998 at 09:50:14AM -0700, Andrew Morgan wrote:
> 
> The more I think about this, the less it seems appropriate for us to
> rely on any uid convention for authentication purposes.  Perhaps it is
> sufficient to state the PAM_RUSER is the user originating the request
> and PAM_USER is the user to be authenticated?
> 
> I think this is so basic, it can even be made to work with Solaris.
> 
> The problem with inferring all this from uids of one sort or another
> is that it means we cannot use PAM for databases and other
> applications that enforce their own security/credential model
> (independent of the kernel).
> 
> Comments?

I understand you ranging the pluggability on the first place.

But I think we should put restrictions on PAMified applications
which helps the developing of modules acting non-trivially
in their session and credentials functions.

I dislike the situation when a module developer find that
his module will not work for some applications
because of different kernel credentials
on pam_setcred(PAM_ESTABLISH_CRED) and pam_setcred(PAM_DELETE_CRED) calls.

It can't be called "pluggability".

I don't think that it helps if we claim that a module shouldn't make assumptions
about kernel credentials of the process.

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().

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().

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.

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.

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.



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