openssh unix dev - May 2004 - pam_setcred fails for "USE_POSIX_THREADS + non-root users + PrivSep yes"

Hello,

We use USE_POSIX_THREADS in our HP-UX build of OpenSSH. When we connect a
non-root user with PAM [pam-kerberos] then I get the following error.

debug3: PAM: opening session
debug1: PAM: reinitializing credentials
PAM: pam_setcred(): Failure setting user credentials

This is particularly for non-root users with PrivSep YES. When I connect to
a root user with PrivSep YES or to a non-root user with PrivSep NO, then no
issues. This is tested on 3.7.1p2  and 3.8.1p1 and two versions behave
alike. This is not the case when USE_POSIX_THREADS is disabled and it works
for PrivSep yes and no for root and non-root users.

Just to check the pid that call the pam_setcred in do_pam_setcred, I used
the getpid() call in the do_pam_setcred function and for both THREAD enabled
and disabled builds, the child pid and the pid that call this function are
the same and inspite of this similarity this problem is seen.

Any help will be much appreciated.

Regards,
Kumar.

[sorry for the previous message, it escaped early]

Kumaresh wrote:
> We use USE_POSIX_THREADS in our HP-UX build of OpenSSH. When we connect a
> non-root user with PAM [pam-kerberos] then I get the following error.
> 
> debug3: PAM: opening session
> debug1: PAM: reinitializing credentials
> PAM: pam_setcred(): Failure setting user credentials
> 
> This is particularly for non-root users with PrivSep YES. When I connect to
> a root user with PrivSep YES or to a non-root user with PrivSep NO, then no
> issues. This is tested on 3.7.1p2  and 3.8.1p1 and two versions behave
> alike. This is not the case when USE_POSIX_THREADS is disabled and it works
> for PrivSep yes and no for root and non-root users.
> 
> Just to check the pid that call the pam_setcred in do_pam_setcred, I used
> the getpid() call in the do_pam_setcred function and for both THREAD
enabled
> and disabled builds, the child pid and the pid that call this function are
> the same and inspite of this similarity this problem is seen.
Try reversing the order of do_pam_session() and do_pam_setcred() in 
session.c.

Different PAM implementations expect different orders (sigh) and 
Trusted-mode HP-UX seems particularly picky about this.

Solaris PAM and OpenPAM expect pam_setcred to be called before 
pam_open_session, whereas LinuxPAM expects the opposite.  (HP-UX's PAM
is based on Sun's).

The Solaris 8 pam_setcred(3PAM) man page says:

      It is typically called after the
      user has been authenticated and after  a  session  has  been
      opened.   See  pam_authenticate(3PAM),  pam_acct_mgmt(3PAM),
      and pam_open_session(3PAM).

Whereas the LinuxPAM pam_setcred(3) man page says:

This function is used to establish, maintain and delete the credentials 
of a user. It should be called after a user has been authenticated  and 
before a session is opened for the user (with pam_open_session(3)).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Darren Tucker wrote:
> Try reversing the order of do_pam_session() and do_pam_setcred() in 
> session.c.
Also try this patch, which removes the pam_setcred(..., 
PAM_REINITIALIZE_CRED) call and see if that helps.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-sshd-no_reinit_pam_creds.patch
Url:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040602/894b16ee/attachment.ksh