Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: building shared library libpam.so.5 make: don't know how to make openpam.3. Stop *** Error code 2 Ah, yes, the man pages are generated during the release process, so you either have to copy them over from the original contrib/openpam directory (or export the new sources on top of the existing directory) or build with -DNO_MAN. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 11 Jan, Dag-Erling Smørgrav wrote: Could you please try this: # cd /usr/src/contrib # mv openpam openpam.orig # svn export svn://svn.des.no/openpam/trunk@526 openpam # cd ../lib/libpam # make depend make all make install [snip] building shared library libpam.so.5 make: don't know how to make openpam.3. Stop *** Error code 2 Other than that, it works great and doesn't get tripped up by my obsolete /etc/pam.conf. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 10 Jan, Dag-Erling Smørgrav wrote: If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. Yeah, I didn't see where the change in question would affect error handling, but I think my first patch suggestion would ignore errors. I thought you were commenting on that in your followup messsage. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Could you please try this: # cd /usr/src/contrib # mv openpam openpam.orig # svn export svn://svn.des.no/openpam/trunk@526 openpam # cd ../lib/libpam # make depend make all make install In addition to the pam.conf issue, the major changes relative to head are reduced log spam, improved log messages in certain error conditions, and a different default password prompt for remote logins. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 9 Jan, Dag-Erling Smørgrav wrote: Don Lewis truck...@freebsd.org writes: The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. I think the code around the end of the loop should look more like: if (ret == PAM_SUCCESS) break; } return (ret); } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. Thank you, Captain Obvious. I am still not confident that simply reverting this commit is the right way to go, because it discards valuable information when an error occurs, especially if an error occurs while parsing an include. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 9 Jan, Dag-Erling Smørgrav wrote: Don Lewis truck...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. Thank you, Captain Obvious. I am still not confident that simply reverting this commit is the right way to go, because it discards valuable information when an error occurs, especially if an error occurs while parsing an include. It wasn't so obvious to me, especially with the gratuitous variable renaming in the diff. After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); The simplest fix for now is probably to revert r487; it applies cleanly except for the first hunk, which is easy to apply manually. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 9 Jan, Dag-Erling Smørgrav wrote: Don Lewis truck...@freebsd.org writes: After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); The simplest fix for now is probably to revert r487; it applies cleanly except for the first hunk, which is easy to apply manually. openpam_configure() checks whether or not pamh-chains[] is NULL, so I figured that was a good test once I figured out how openpam_parse_chain() was returning its results. Once you decide on a fix, I can move my old /etc/pam.conf back to test it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
