[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compile error in current CVS, src/server.c:5500
From: |
Mark D. Baushke |
Subject: |
Re: Compile error in current CVS, src/server.c:5500 |
Date: |
Mon, 21 Jul 2003 11:59:25 -0700 |
Derek Robert Price <derek@ximbiot.com> writes:
> Brian Murphy wrote:
>
> > Hi,
> >
> > Here is the fix. I didn't like the use of a fake error EACCES
> > in this situation, I prefer 0. EACCES refers to file access
> > failures not authentication / login failures as far as I'm aware.
>
>
> What, exactly, is wrong with calling pam_strerror() to get an error
> message from PAM for pam_end() errors and printing that, as Mark
> mentioned?
It seems that pam_strerror() has the first argument that is expected to
be a pointer to a pam_handle_t and there is concern about what happens
if pam_strerror() is called with an invalid pam_handle_t. So, if the
handle has already been destroyed, should it still be possible to use
pam_strerror() or not? I *thought* it should be, but I have not played
with it.
The FreeBSD implementation appears to deal with NULL being passed as the
pam_handle_t for purposes of getting errnum returned properly, but there
is some odd glue for UGLY_HACK_FOR_PRIOR_BEHAVIOR_SUPPORT wherein not
having a valid pam_handle_t might cause some more problems. So, it is
possible that not all implementations of pam will be as friendly.
I suppose another configure test could determine if it works or not...
At the very least, the return value of the pam_end() function call
should be captured and returned as an integer on the error string.
I would find it acceptable to use "error 0 ..." rather than the "error
EACCESS" I provided as a suggestion previously. I am not trying to force
thru how the PAM code is implemented. I just want it to be possible for
it to be supported when bugs are reported from the field.
> For that matter, why isn't this being done for returns
> other than PAM_SUCCESS in the preceding calls to pam_start(),
> pam_authenticate(), and pam_acct_mgmt()?
Good point. Those really should be handled as well.
As an FYI, here is the pam_strerror.c source code I have on a FreeBSD 4.x
system... I am sure that there are other implementations out there.
I would hope it would be possible to turn the error numbers returned out
of the pam library into meaningful text. Otherwise, assertions that PAM
is a reasonable and mature API would seem to me to be a bit of a joke.
Enjoy!
-- Mark
------- FreeBSD contrib/libpam/pam_strerror.c -------
/* pam_strerror.c */
/* pam_strerror.c,v 1.1.1.1 1998/07/09 22:10:22 jdp Exp
*
* pam_strerror.c,v
* Revision 1.1.1.1 1998/07/09 22:10:22 jdp
* Virgin import of Linux-PAM-0.65, slightly stripped down.
*
* Revision 1.6 1997/01/04 20:12:02 morgan
* replaced conditional FAIL_NOW with ABORT
*
* Revision 1.5 1996/07/07 23:58:56 morgan
* corrected "... " to "..."
*
* Revision 1.4 1996/06/02 08:03:29 morgan
* spelling correction
*
* Revision 1.3 1996/03/16 23:08:54 morgan
* PAM --> Linux-PAM ;)
*
*/
#include "pam_private.h"
const char *pam_strerror(pam_handle_t *pamh, int errnum)
{
#ifdef UGLY_HACK_FOR_PRIOR_BEHAVIOR_SUPPORT /* will be removed from v 1.0 */
int possible_error;
possible_error = (int) pamh;
if (!(possible_error >= 0 && possible_error <= PAM_BAD_ITEM)) {
possible_error = errnum;
}
/* mask standard behavior to use possible_error variable. */
#define errnum possible_error
#endif /* UGLY_HACK_FOR_PRIOR_BEHAVIOR_SUPPORT */
switch (errnum) {
case PAM_SUCCESS:
return "Success";
case PAM_ABORT:
return "Critical error - immediate abort";
case PAM_OPEN_ERR:
return "dlopen() failure";
case PAM_SYMBOL_ERR:
return "Symbol not found";
case PAM_SERVICE_ERR:
return "Error in service module";
case PAM_SYSTEM_ERR:
return "System error";
case PAM_BUF_ERR:
return "Memory buffer error";
case PAM_PERM_DENIED:
return "Permission denied";
case PAM_AUTH_ERR:
return "Authentication failure";
case PAM_CRED_INSUFFICIENT:
return "Insufficient credentials to access authentication data";
case PAM_AUTHINFO_UNAVAIL:
return "Authentication service cannot retrieve authentication info.";
case PAM_USER_UNKNOWN:
return "User not known to the underlying authentication module";
case PAM_MAXTRIES:
return "Have exhasted maximum number of retries for service.";
case PAM_NEW_AUTHTOK_REQD:
return "Authentication token is no longer valid; new one required.";
case PAM_ACCT_EXPIRED:
return "User account has expired";
case PAM_SESSION_ERR:
return "Cannot make/remove an entry for the specified session";
case PAM_CRED_UNAVAIL:
return "Authentication service cannot retrieve user credentials";
case PAM_CRED_EXPIRED:
return "User credentials expired";
case PAM_CRED_ERR:
return "Failure setting user credentials";
case PAM_NO_MODULE_DATA:
return "No module specific data is present";
case PAM_BAD_ITEM:
return "Bad item passed to pam_*_item()";
case PAM_CONV_ERR:
return "Conversation error";
case PAM_AUTHTOK_ERR:
return "Authentication token manipulation error";
case PAM_AUTHTOK_RECOVER_ERR:
return "Authentication information cannot be recovered";
case PAM_AUTHTOK_LOCK_BUSY:
return "Authentication token lock busy";
case PAM_AUTHTOK_DISABLE_AGING:
return "Authentication token aging disabled";
case PAM_TRY_AGAIN:
return "Failed preliminary check by password service";
case PAM_IGNORE:
return "Please ignore underlying account module";
case PAM_MODULE_UNKNOWN:
return "Module is unknown";
case PAM_AUTHTOK_EXPIRED:
return "Authentication token expired";
case PAM_CONV_AGAIN:
return "Conversation is waiting for event";
case PAM_INCOMPLETE:
return "Application needs to call libpam again";
}
return "Unknown Linux-PAM error (need to upgrde libpam?)";
}
- Compile error in current CVS, src/server.c:5500, Pavel Roskin, 2003/07/20
- Re: Compile error in current CVS, src/server.c:5500, Mark D. Baushke, 2003/07/20
- Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Mark D. Baushke, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Mark D. Baushke, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Mark D. Baushke, 2003/07/21
Re: Compile error in current CVS, src/server.c:5500, Brian Murphy, 2003/07/21
Re: Compile error in current CVS, src/server.c:5500, Brian Murphy, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Mark D. Baushke, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Brian Murphy, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Brian Murphy, 2003/07/21
- Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21
Re: Compile error in current CVS, src/server.c:5500, Brian Murphy, 2003/07/21
Re: Compile error in current CVS, src/server.c:5500, Derek Robert Price, 2003/07/21