Bug 564 - new PAM code only calls pam_acct_mgmt for challenge-response clients
Summary: new PAM code only calls pam_acct_mgmt for challenge-response clients
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: PAM support (show other bugs)
Version: -current
Hardware: All Linux
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords: patch
Depends on:
Blocks: 627
  Show dependency treegraph
 
Reported: 2003-05-14 14:51 AEST by Damien Miller
Modified: 2004-04-14 12:24 AEST (History)
0 users

See Also:


Attachments
Perform PAM account checks (9.43 KB, patch)
2003-08-24 22:53 AEST, Damien Miller
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Miller 2003-05-14 14:51:35 AEST
The new PAM code only calls pam_acct_mgmt for challenge-response clients. Unsure
whether this is a problem, but it is certainly a change in behaviour.

We used to do tests like:

#ifdef USE_PAM
	if (!use_privsep && authenticated && authctxt->user && 
	    !do_pam_account(authctxt->user, NULL))
		authenticated = 0;
#endif /* USE_PAM */
Comment 1 Damien Miller 2003-07-30 11:48:26 AEST
Maybe UsePAM should be a tri-state: "kbd-int", "no" or "always". This is ugly -
suggestions wanted.
Comment 2 Damien Miller 2003-08-24 22:53:15 AEST
Created attachment 369 [details]
Perform PAM account checks

This patch adds PAM account checks after authentication. Tested with passwd and
pubkey auth, protos 1 and 2, with and without privsep.

Doesn't make PAM chauthtok work - that is tricky with privsep.
Comment 3 Darren Tucker 2003-08-25 11:42:16 AEST
I've looked at patch id #369.

This part is useless:

diff -u -r1.246 session.c
--- session.c   13 Aug 2003 10:31:05 -0000      1.246
+++ session.c   24 Aug 2003 12:44:32 -0000
@@ -719,6 +719,11 @@
        if (options.use_pam && is_pam_password_change_required()) {
                print_pam_messages();
                do_pam_chauthtok();
+               
+               /* Permit forwardings if we succeed here */
+               no_port_forwarding_flag &= ~2;
+               no_agent_forwarding_flag &= ~2;
+               no_x11_forwarding_flag &= ~2;
        }
 #endif

By the time that runs, you are in the process that later execs the user's shell. 
  The forwarding flags you need to reset are in its parent.

The patch regress tested OK on Redhat 8.

Something funny is wrong on HP-UX & Solaris (dynamic forwarding tests fail, not 
sure why yet).
Comment 4 Darren Tucker 2003-08-25 13:02:09 AEST
Comment on attachment 369 [details]
Perform PAM account checks

The problem with Solaris and HP-UX was with the tests, the code itself is fine.

Passed regression on Solaris 8 & HP-UX 11.00.

ok dtucker@, but the code in session.c should be removed or commented that it
can't work.
Comment 5 Darren Tucker 2003-08-25 13:02:14 AEST
Comment on attachment 369 [details]
Perform PAM account checks

The problem with Solaris and HP-UX was with the tests, the code itself is fine.

Passed regression on Solaris 8 & HP-UX 11.00.

ok dtucker@, but the code in session.c should be removed or commented that it
can't work.
Comment 6 Damien Miller 2003-08-25 13:09:39 AEST
Applied
Comment 7 Damien Miller 2004-04-14 12:24:18 AEST
Mass change of RESOLVED bugs to CLOSED