RE: Use of "[success=ok ...]" form

["Patterson, Ross" <ROSS PATTERSON ca com>]

Andrew Morgan <morgan@transmeta.com> writes:
> Could you supply more information?

Sure, I'm full of it :-)
 
> The pam.d/login file you supply makes no reference to pam_warn, but I
> see entries for this in the log. I'm guessing that they are from your
> 'other' file, but I'd like to know what it contains..

Good guess ... The system I'm testing with is SuSE-based, and 
is distributed with the following /etc/pam.d/other:

#%PAM-1.0 
auth	   required	/lib/security/pam_warn.so 
auth     required /lib/security/pam_unix.so	#nullok set_setrpc 
account  required	/lib/security/pam_warn.so 
account  required /lib/security/pam_unix.so 
password required	/lib/security/pam_warn.so 
password required	/lib/security/pam_pwcheck.so	use_cracklib 
password required /lib/security/pam_unix.so	use_first_pass use_authtok 
session  required /lib/security/pam_warn.so 
session  required /lib/security/pam_unix.so	debug # none or trace 

 
> "Patterson, Ross" wrote:
> > auth     optional      /lib/security/pam_rc.so 3 0
> 
> And then you explain:
> 
> > syslog(), the latter exits with the return code specified as it's
> > parameter ("3" is PAM_SERVICE_ERR, "0" is PAM_SUCCESS).  As far as I
> > can tell, they should behave identically, yet they do not.  
> I got the
> > supposedly-correct [...] form from
> 
> But this doesn't explain the 3 _and_ the 0 in the above argument list.
> If there had been one argument, I think I would understand, but there
> isn't.

Sorry, I should have been clearer.  Since some PAM module-types
contain more than one routine (e.g. "auth" is pam_sm_authenticate() 
and pam_sm_setcred()), I wanted to be able to control both return 
codes.  The first return code ("3"  above) is for the first routine
(pam_sm_authenticate()), and the second is for the second.  Here's 
the full source for pam_rc.c.  No comments, but it's a throw-away
and pretty simple.

#ifdef PAM_STATIC
	#define PAM_SM_ACCOUNT
	#define PAM_SM_AUTH
	#define PAM_SM_PASSWORD
	#define PAM_SM_SESISON
#endif

#include <stdlib.h>
#include <security/pam_modules.h>

#ifdef PAM_STATIC
struct pam_module _modstruct = {
	"pam_dump_info",
	pam_sm_authenticate,
	pam_sm_setcred,
	pam_sm_acct_mgmt,
	pam_sm_open_session, 
	pam_sm_close_session, 
	pam_sm_chauthtok
};
#endif /* PAM_STATIC */

PAM_EXTERN int
pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
	int rc = PAM_SUCCESS;

	if (argc >= 1)
		rc = atoi(argv[0]);
	syslog(LOG_DEBUG, __FILE__ ": %s: returning %d", __FUNCTION__, rc);
	return rc;
}

PAM_EXTERN int
pam_sm_setcred(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
	int rc = PAM_SUCCESS;

	if (argc >= 2)
		rc = atoi(argv[1]);
	syslog(LOG_DEBUG, __FILE__ ": %s: returning %d", __FUNCTION__, rc);
	return rc;
}

PAM_EXTERN int
pam_sm_open_session(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
	int rc = PAM_SUCCESS;

	if (argc >= 1)
		rc = atoi(argv[0]);
	syslog(LOG_DEBUG, __FILE__ ": %s: returning %d", __FUNCTION__, rc);
	return rc;
}

PAM_EXTERN int
pam_sm_close_session(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
	int rc = PAM_SUCCESS;

	if (argc >= 2)
		rc = atoi(argv[1]);
	syslog(LOG_DEBUG, __FILE__ ": %s: returning %d", __FUNCTION__, rc);
	return rc;
}

PAM_EXTERN int
pam_sm_chauthtok(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
	int rc = PAM_SUCCESS;

	if (argc >= 1)
		rc = atoi(argv[0]);
	syslog(LOG_DEBUG, __FILE__ ": %s: returning %d", __FUNCTION__, rc);
	return rc;
}

PAM_EXTERN int
pam_sm_acct_mgmt(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
	int rc = PAM_SUCCESS;

	if (argc >= 1)
		rc = atoi(argv[0]);
	syslog(LOG_DEBUG, __FILE__ ": %s: returning %d", __FUNCTION__, rc);
	return rc;
}


> I should say that I have tried to reproduce your problem with 
> pam_debug
> and pam_warn against top of trunk CVS and have not had any luck. That
> is, both flavors of control description work identically for 
> me. Are you
> sure that your pam_rc.so module works as you have described it?

Yup, it's pretty simple (see above).  Of course, pam_rc isn't the
module I'm trying to test, rather it's the smallest, easiest-to-share
equivalent.  Trust me, you don't want to deal with the IBM z/OS 
mainframe that's in the back-end of my *real* module :-)

I'm not surprised that you can't reproduce it, I can't explain why
it's happening given the code I read in libpam/pam_handlers.c and
pam_dispatch.c!

As puzzled as ever,
Ross Patterson
Computer Associates
P.S. If you want a formal bug report, just say so.  RAP