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 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@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@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@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list
