Another round of testing calls.

Ed Phillips ed at UDel.Edu
Thu Oct 25 07:23:32 EST 2001


On Wed, 24 Oct 2001 mouring at etoh.eviladmin.org wrote:

> Date: Wed, 24 Oct 2001 16:03:40 -0500 (CDT)
> From: mouring at etoh.eviladmin.org
> To: Ed Phillips <ed at UDel.Edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Another round of testing calls.
>
>
> How do you enforce PAM limits without opening a session then?

There are no "limits" enforced by pam_sm_open_session() - the current
pam_unix.so just makes a lastlog entry with the TTY set in the PAM handle.
All the "limits" (I assume you mean password expiration and account
expiration and invalid account type stuff) are handled by the
pam_sm_acct_mgmt() (and possibly even pam_sm_authenticate()) which are
also provided pam_unix.so on Sol8 (along with others like pam_nisplus.so,
pam_ldap.so, etc.).  I'll check into the details and see if we could just
"not call pam_open_session() for non-interactive mode" or if we need to
call the acct mgmt front-end in some way first.  My guess is that if you
don't call pam_open_session(), it will prevent the crash, but then the
rest of the PAM calls will eventually get an error that indicates that the
password needs to be changed... and if we don't handle that for
non-interactive mode (like in.rshd), it's no big deal - the user will have
to login interactively first then he can run commands non-interactively.

I'll try to delve deeper tomorrow morning...

	Ed

>
> - Ben
>
> On Wed, 24 Oct 2001, Ed Phillips wrote:
>
> > Is it possible that this is a direct result of using the kludge -
> > specifying a bogus tty name which can't possibly be used to fetch a
> > password?  Probably, sshd should not call pam_open_session() in the case
> > where we are running in non-interactive mode - and sshd should just exit
> > with a "password expired" error if the password needs to be changed
> > in.rshd on Sol8 does not does not call the PAM session stuff.
> > pam_unix.so on Sol8 has a pam_sm_open_session() which requires the tty
> > name to be available (and my guess is that it must be valid as well -
> > hence the problems with not passing a tty name).  Sure, it's a bug in Sol8
> > pam_unix.so, but the docs are pretty thin regarding what
> > pam_sm_open_session() is supposed to do and whether the PAM_TTY is
> > required.  My guess that PAM_TTY is actually a required parameter (if
> > you're going to do PAM session stuff) and unexpected results will occur if
> > you just fill it with a bogus string.
> >
> > 	Ed
> >
> > On Wed, 24 Oct 2001 mouring at etoh.eviladmin.org wrote:
> >
> > > Date: Wed, 24 Oct 2001 09:27:48 -0500 (CDT)
> > > From: mouring at etoh.eviladmin.org
> > > Cc: "Dost, Alexander" <Alexander.Dost at drkw.com>, openssh-unix-dev at mindrot.org
> > > Subject: Re: Another round of testing calls.
> > >
> > >
> > > If PAM is doing the password change, then I have to agree with Markus.
> > > Could one of our Lurking Sun experts reproduce this and check if there is
> > > a bug in their PAM code or if we are missing a bit of code?
> > >
> > > - Ben
> > >
> > > On Wed, 24 Oct 2001, Markus Friedl wrote:
> > >
> > > > On Wed, Oct 24, 2001 at 10:46:57AM +0200, Dost, Alexander wrote:
> > > > > Is the problem with clear-text passwords after using the kludge on Sol8
> > > > > known and will it be fixed ?
> > > > > I didn't see any reply on this problem.
> > > >
> > > > this is probably a bug in the PAM: either they should
> > > > not depend on the TTY kludge or not ask for a password
> > > > if there is not TYY.
> > > >
> > > > -m
> > > >
> > >
> >
> > Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
> > Systems Programmer III, Network and Systems Services
> > finger -l ed at polycut.nss.udel.edu for PGP public key
> >
> >
>

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key




More information about the openssh-unix-dev mailing list