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
