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

Re: Pam-list digest, Vol 1 #146 - 5 msgs



To All;

I have a problem with PAM in RedHat 6.2.

I can boot into single user mode with no problem.
However, when I try to go multi-user, it tells me that
it doesn't recognize user root or any other user.  I've
copied the passwd file, shadow file, pam.d directory and
all /lib/security and /etc/security files intact from a 
running 6.2 system.  What can be wrong?  I need this for
the Linux Expo next week and have to have this running
by Friday at the latest.

Please help....

Regards,

Ken Beversdorf
Lynuxworks Inc.
kbeversdorf@lynuxworks.com





pam-list-request@redhat.com wrote:
> 
> Send Pam-list mailing list submissions to
>         pam-list@redhat.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://listman.redhat.com/mailman/listinfo/pam-list
> or, via email, send a message with subject or body 'help' to
>         pam-list-request@redhat.com
> 
> You can reach the person managing the list at
>         pam-list-admin@redhat.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pam-list digest..."
> 
>   -----------------------------------------------------------------
> Today's Topics:
> 
>   1. Re: I want to do a ISP Pam module! Can anyone help (ken rhodes)
>   2. Re: Linux PAM fixes (Nicolas Williams)
>   3. Re: Linux PAM fixes (David J. MacKenzie)
>   4. Re: Linux PAM fixes (Nicolas Williams)
>   5. Re: Linux PAM fixes (Andrew Morgan)
> 
>   -----------------------------------------------------------------
> 
> Subject: Re: I want to do a ISP Pam module! Can anyone help
> Date: Wed, 24 Jan 2001 13:59:21 -0800
> From: ken rhodes <webmaster@webside.ca>
> Reply-To: pam-list@redhat.com
> To: pam-list@redhat.com
> References: <3A6CD621.FCE417DB@webside.ca> <200101230340.f0N3eud28093@mail.redhat.com>
> 
> Thank you for your thoughts Mike Glover;
>         Here are a few questions back!
> 
> 1) I have never programed in C, but I do understand how it works because
> I have only programed in COBOL, FORTRAN, Pascal, Clipper, and Perl.
> 
> 2) I will download the new pam source files, and I understand I can
> either modify the Tally or the Limit module to access the database and
> give me the ability to limit to one at a time.
> 
> 3) For the 30 hour and 90 hour accounts. I am currently using the
> messages file, but if the system administrator kills the account there
> is no log that the modem has exited, and there is no live data were I
> can let the user know how may hours they have.
> 
> 4) As for the reason I believed I had to use PAM to have access to the
> live data on that the users are doing something or not. I am sorry but I
> do not know how to access the information to do these projects out side
> of the PAM module.
> 
> 5) Since all these projects have to deal with user accounts and there
> ability to log on or stay on. Is PAM not a natural place to put such a
> module?
> 
> Mike Glover wrote:
> >
> > The first one should be pretty straightforward with PAM.  The second two
> > are probably best solved elsewhere.  My thoughts are below...
> >
> > On Mon, 22 Jan 2001, ken rhodes wrote:
> > >       Hi;
> > >
> > >       For those who would like to help, or are interested. I am reading the
> > > PAM Documentation. I understand I have to program in C. I am just having
> > > a problem understanding where to start.
> > >
> > > What I need the module to do;
> > >    1) Restrict logins to having only one login at a time. ( With the
> > > exception of the system administration team)
> >
> >    You may be able to do this with existing modules.  What you want to do
> > is set up a second user database that contains only the currently logged
> > in users, then refuse a login if the user is already in the database.  If
> > they're not there, add them.  This would need to be last in the stack.
> >
> > >    2) Track limited accounts. Maybe even e-mail the account, or pop up a
> > > warning screen when they are at there limit. I need this programmable
> > > because right now we have 30 hour and 90 hour accounts, and we may add
> > > more in the future. I also need this part to email the accounting person
> > > with the amount these limited accounts are over for billing purposes.
> >
> >    Where do you store user's monthly usage stats?  What granularity do you
> > need? (i.e is it enough to notify a user within 15 minutes of their going
> > over limit? 5 minutes? 1?)  The easiest solution I see is setting up a cron
> > job to query your usage stats every x minutes,  noticing who's over limit,
> > and notifying them and your accounting person.
> >
> >    If you're not keeping usage stats, then PAM can help you do that.
> >
> > >    3) I would also like this module to check to see when all of our
> > > phone lines are busy, and kick off people who have not done anything for
> > > 20 minutes or more.
> >
> >    This is probably best done outside of PAM.  Write a daemon to watch your
> > phone lines and notice when they're all used.  Then check the output of
> > 'w' or read /proc to find out who's been idle.  then 'kill -TERM
> > <login_shell>'
> >
> > -mike
> >
> > >
> > > >From all of my reading in the PAM modules there are no modules that fit
> > > in this category, but if there is a teem already working on a project
> > > like this I would like to start to help; Otherwise, I would like to set
> > > up a project team for this project.
> > >
> > > Thank you;
> > > Ken Rhodes
> > > Webmaster
> > > http://webside.ca
> > >
> > >
> > >
> > > _______________________________________________
> > > Pam-list mailing list
> > > Pam-list@redhat.com
> > > https://listman.redhat.com/mailman/listinfo/pam-list
> > >
> > --
> >
> > GnuPG key available at http://devel.duluoz.net/pubkey.asc
> > Key ID = 1024D/9A256AE5 1999-11-13 Mike Glover <mpg4@duluoz.net>
> > Key fingerprint = EF6E 8BCB 4810 E98C F0FD  4596 367A 32B7 9A25 6AE5
> >
> > _______________________________________________
> > Pam-list mailing list
> > Pam-list@redhat.com
> > https://listman.redhat.com/mailman/listinfo/pam-list
> 
>   -----------------------------------------------------------------
> 
> Subject: Re: Linux PAM fixes
> Date: Wed, 24 Jan 2001 10:53:35 -0500
> From: Nicolas Williams <Nicolas.Williams@ubsw.com>
> Reply-To: pam-list@redhat.com
> To: pam-list@redhat.com
> CC: flepied@mandrakesoft.com, johnsonm@redhat.com, nalin@redhat.com,
>      chmouel@mandrakesoft.com, yoann@mandrakesoft.com,
>      snailtalk@mandrakesoft.com, pablo@mandrakesoft.com, jbj@redhat.com,
>      bero@linux-mandrake.com, morgan@linux.kernel.org, okir@caldera.de,
>      netbug@ftp.uk.linux.org, util-linux@math.uio.no, djm@uu.net
> References: <20010123061802.6D4401DF@air.web.us.uu.net>
> 
> On Tue, Jan 23, 2001 at 01:18:02AM -0500, David MacKenzie wrote:
> > Hello!  I'm sending this mail to addresses I found in documentation
> > for several Linux packages or in changelog entries in their spec files
> > for Red Hat or Mandrake Linux.  Feel free to forward this message to
> > anyone interested that I missed.
> 
> Wow. Very cool fixes and summary.
> 
> > 2. The utilities call pam_setcred() before, instead of after,
> >    pam_open_session().  According to the Linux-PAM docs, the RFC
> >    example code, and the Solaris man page, pam_setcred() should be
> >    called after pam_open_session().
> 
> But pam_setcred() can be called without calling pam_open_session().
> 
> Right?
> 
> Since su shouldn't call the open/close session calls, should it call
> pam_setcred()? In the case of pam_krb5 that would make sense, as long as
> pam_setcred() is called again to destroy the ccache when the user exits
> the su session. In fact, su might well be useless in a Kerberos
> environment unless it does call pam_setcred().
> 
> > 7. pam_krb5 makes the pam_sm_{open,close}_session() calls be
> >    duplicates of the pam_sm_setcred() calls, probably to work around
> >    bugs 1 and 6.  Once they are fixed, pam_krb5 can be corrected, and
> >    the pam_sm_open_session() and pam_sm_close_session() reduced to
> >    no-ops that return PAM_SUCCESS, as they should be.
> 
> The pam_krb5 pam_sm_close_session() method can do some useful things:
> 
>  - print the time of last login (i.e., last initial TGT issuance);
>    granted, MIT doesn't maintain that datum, so it's useless with MIT
>    krb5
> 
>  - warn the user about upcoming password expiration (e.g., "Your
>    password will expire in 3 days")
> 
> By the way, there are a number of different pam_krb5 implementations
> out there. Few get password aging right (i.e., few give a user with an
> expired password the chance to change their password). Kerberos
> authentication should be done via the newer
> krb5_get_init_creds_with_password() API, not the krb5_get_in_tkt*()
> APIs; the former supports password aging, the latter doesn't, and the
> former accepts pointers to a krb5_prompter function and related data
> which can be used to translate krb5_prompts to PAM prompts. I believe
> that Frank Cusak's pam_krb5 calls krb5_get_init_creds_with_password();
> Sun's doesn't.
> 
> This brings up an issue with PAM and the Kerberos password aging model,
> namely that with Kerberos an expired password must be changed BEFORE
> proceeding with authentication, but in the PAM model authentication is
> done first, then authorization and only then can password expiration be
> discovered and corrected (i.e., it's pam_acct_mgmt()'s job to indicate
> the password expired case to the application so it cam call
> pam_chauthtok()).
> 
> I think the solution is for pam_krb5:pam_sm_authenticate() to work
> through changing a user's old password when it's expired, without
> setting the PAM_*AUTHTOK items, leaving that to
> pam_krb5:pam_sm_chauthtok() and using pam_set_data() to keep state.
> 
> Alternatively, pam_krb5:pam_sm_authenticate() could provisionally return
> PAM_SUCCESS in password expired cases, then pam_krb5:pam_sm_acct_mgmt()
> can return PAM_NEW_AUTHTOK_REQD, and then pam_krb5:pam_sm_chauthtok()
> return PAM_SUCCESS/PAM_PERM_DENIED/PAM_AUTH_ERR and so on. Applications
> MUST treat pam_chauthtok() as if it were pam_authenticate() in such
> cases and deny access unless pam_chauthtok() returns PAM_SUCCESS.
> 
> The latter solution is harder to implement in pam_krb5 than the former,
> needing several calls to krb5_get_init_creds_with_password() instead of
> just one call.
> 
> Clarification in this area would be appreciated. I would prefer the
> simpler approach.
> 
> > 8. pam_krb5 lacks an account management function to check .k5login for
> >    authorization.
> > 9. pam_krb5 doesn't check some malloc calls for failure.
> ...
> 
> This depends on which implementation of pam_krb5 you're referring to...
> 
>:)
> 
> Nico
> --
> 
>   -----------------------------------------------------------------
> 
> Subject: Re: Linux PAM fixes
> Date: Wed, 24 Jan 2001 13:38:21 -0500
> From: "David J. MacKenzie" <djm@web.us.uu.net>
> Reply-To: pam-list@redhat.com
> To: pam-list@redhat.com, flepied@mandrakesoft.com,
>      johnsonm@redhat.com, nalin@redhat.com, chmouel@mandrakesoft.com,
>      yoann@mandrakesoft.com, snailtalk@mandrakesoft.com,
>      pablo@mandrakesoft.com, jbj@redhat.com, bero@linux-mandrake.com,
>      morgan@linux.kernel.org, okir@caldera.de, netbug@ftp.uk.linux.org,
>      util-linux@math.uio.no, djm@uu.net
> 
> > But pam_setcred() can be called without calling pam_open_session().
> >
> > Right?
> 
> Right.
> 
> > Since su shouldn't call the open/close session calls, should it call
> > pam_setcred()? In the case of pam_krb5 that would make sense, as long as
> > pam_setcred() is called again to destroy the ccache when the user exits
> > the su session. In fact, su might well be useless in a Kerberos
> > environment unless it does call pam_setcred().
> 
> Right, su should call pam_setcred to both create and delete the credentials.
> The current distribution of su in Linux-Mandrake sh-utils only calls it
> to create them.  I suspect other Linux distributions are using the
> same PAM patches, but I haven't checked.
> 
> > The pam_krb5 pam_sm_close_session() method can do some useful things:
> >
> >  - print the time of last login (i.e., last initial TGT issuance);
> >    granted, MIT doesn't maintain that datum, so it's useless with MIT
> >    krb5
> >
> >  - warn the user about upcoming password expiration (e.g., "Your
> >    password will expire in 3 days")
> >
> > By the way, there are a number of different pam_krb5 implementations
> > out there.
> 
> Sorry, I should have been explicit.  I'm referring to the Red Hat 7 one.
> I've also looked at Frank Cusack's, which is in the FreeBSD ports collection
> and doesn't have most of the problems I described.
> 
> > This brings up an issue with PAM and the Kerberos password aging model,
> > namely that with Kerberos an expired password must be changed BEFORE
> > proceeding with authentication, but in the PAM model authentication is
> > done first, then authorization and only then can password expiration be
> > discovered and corrected (i.e., it's pam_acct_mgmt()'s job to indicate
> > the password expired case to the application so it cam call
> > pam_chauthtok()).
> 
> I don't have strong opinions about how to handle password aging, as I
> don't use it.
> 
> If anyone in the recipient list doesn't want to be in on any further
> discussions of these topics, just reply to the rest of us and we'll
> leave you out of any future messages.  I don't expect (or hope) that
> a long discussion will ensue, though.
> 
>   -----------------------------------------------------------------
> 
> Subject: Re: Linux PAM fixes
> Date: Wed, 24 Jan 2001 10:53:34 -0500
> From: Nicolas Williams <Nicolas.Williams@ubsw.com>
> Reply-To: pam-list@redhat.com
> To: pam-list@redhat.com
> CC: djm@uu.net
> References: <20010123061802.6D4401DF@air.web.us.uu.net>
> 
> [Resend. First post was rejected because it had too many receipients.]
> 
> On Tue, Jan 23, 2001 at 01:18:02AM -0500, David MacKenzie wrote:
> > Hello!  I'm sending this mail to addresses I found in documentation
> > for several Linux packages or in changelog entries in their spec files
> > for Red Hat or Mandrake Linux.  Feel free to forward this message to
> > anyone interested that I missed.
> 
> Wow. Very cool fixes and summary.
> 
> > 2. The utilities call pam_setcred() before, instead of after,
> >    pam_open_session().  According to the Linux-PAM docs, the RFC
> >    example code, and the Solaris man page, pam_setcred() should be
> >    called after pam_open_session().
> 
> But pam_setcred() can be called without calling pam_open_session().
> 
> Right?
> 
> Since su shouldn't call the open/close session calls, should it call
> pam_setcred()? In the case of pam_krb5 that would make sense, as long as
> pam_setcred() is called again to destroy the ccache when the user exits
> the su session. In fact, su might well be useless in a Kerberos
> environment unless it does call pam_setcred().
> 
> > 7. pam_krb5 makes the pam_sm_{open,close}_session() calls be
> >    duplicates of the pam_sm_setcred() calls, probably to work around
> >    bugs 1 and 6.  Once they are fixed, pam_krb5 can be corrected, and
> >    the pam_sm_open_session() and pam_sm_close_session() reduced to
> >    no-ops that return PAM_SUCCESS, as they should be.
> 
> The pam_krb5 pam_sm_close_session() method can do some useful things:
> 
>  - print the time of last login (i.e., last initial TGT issuance);
>    granted, MIT doesn't maintain that datum, so it's useless with MIT
>    krb5
> 
>  - warn the user about upcoming password expiration (e.g., "Your
>    password will expire in 3 days")
> 
> By the way, there are a number of different pam_krb5 implementations
> out there. Few get password aging right (i.e., few give a user with an
> expired password the chance to change their password). Kerberos
> authentication should be done via the newer
> krb5_get_init_creds_with_password() API, not the krb5_get_in_tkt*()
> APIs; the former supports password aging, the latter doesn't, and the
> former accepts pointers to a krb5_prompter function and related data
> which can be used to translate krb5_prompts to PAM prompts. I believe
> that Frank Cusak's pam_krb5 calls krb5_get_init_creds_with_password();
> Sun's doesn't.
> 
> This brings up an issue with PAM and the Kerberos password aging model,
> namely that with Kerberos an expired password must be changed BEFORE
> proceeding with authentication, but in the PAM model authentication is
> done first, then authorization and only then can password expiration be
> discovered and corrected (i.e., it's pam_acct_mgmt()'s job to indicate
> the password expired case to the application so it cam call
> pam_chauthtok()).
> 
> I think the solution is for pam_krb5:pam_sm_authenticate() to work
> through changing a user's old password when it's expired, without
> setting the PAM_*AUTHTOK items, leaving that to
> pam_krb5:pam_sm_chauthtok() and using pam_set_data() to keep state.
> 
> Alternatively, pam_krb5:pam_sm_authenticate() could provisionally return
> PAM_SUCCESS in password expired cases, then pam_krb5:pam_sm_acct_mgmt()
> can return PAM_NEW_AUTHTOK_REQD, and then pam_krb5:pam_sm_chauthtok()
> return PAM_SUCCESS/PAM_PERM_DENIED/PAM_AUTH_ERR and so on. Applications
> MUST treat pam_chauthtok() as if it were pam_authenticate() in such
> cases and deny access unless pam_chauthtok() returns PAM_SUCCESS.
> 
> The latter solution is harder to implement in pam_krb5 than the former,
> needing several calls to krb5_get_init_creds_with_password() instead of
> just one call.
> 
> Clarification in this area would be appreciated. I would prefer the
> simpler approach.
> 
> > 8. pam_krb5 lacks an account management function to check .k5login for
> >    authorization.
> > 9. pam_krb5 doesn't check some malloc calls for failure.
> ...
> 
> This depends on which implementation of pam_krb5 you're referring to...
> 
>:)
> 
> Nico
> --
> 
>   -----------------------------------------------------------------
> 
> Subject: Re: Linux PAM fixes
> Date: Thu, 25 Jan 2001 08:40:30 -0800
> From: Andrew Morgan <morgan@transmeta.com>
> Reply-To: pam-list@redhat.com
> Organization: Transmeta Corp.
> To: pam-list@redhat.com
> References: <20010124183821.B7A9312686@jenkins.web.us.uu.net>
> 
> "David J. MacKenzie" wrote:
> > Right, su should call pam_setcred to both create and delete the credentials.
> > The current distribution of su in Linux-Mandrake sh-utils only calls it
> > to create them.  I suspect other Linux distributions are using the
> > same PAM patches, but I haven't checked.
> 
> I just want to say that I don't believe that su should skip the session
> calls. Having the hooks for session calls is something the admin can
> choose to use or not use as they see fit. (They can always put
> pam_permit.so modules to make the calls no-ops, but for auditing reasons
> these hooks are very useful to the admin.)
> 
> BTW, I realize that folk prefer to modify existing applications to
> support PAM, but there are some reference applications available for
> things like login and su here:
> 
> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/applications/SimplePAMApps/pamapps/?cvsroot=pam
> 
> I'd be interested if folk find the stated 'linux utility' problems with
> these applications.
> 
> Cheers
> 
> Andrew
> 
>   -----------------------------------------------------------------
> _______________________________________________
> Pam-list mailing list
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list





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