On Wed, Apr 25, 2007 at 12:43:27PM +0200, Robert Wolf wrote:
> I am not C & PAM profi programmer, but I think I found a two bugs in PAM 
> source
> code regarding to this functionality bug. Both bugs are in the
> Linux-PAM/modules/pam_unix/pam_unix_acct.c in the function PAM_EXTERN int
> pam_sm_acct_mgmt:

> 1) in the code, there is a condition "if (!strcmp( pwent->pw_passwd, "*NP*" ))
> { /* NIS+ */" for NIS records. If the system do not use NIS, then next
> condition "else if (_unix_shadowed (pwent))" check if the pwent has shadow
> record. If shadow record exists, it reads it "spent = _pammodutil_getspnam
> (pamh, uname);". But if the shadow record does not exist, it returns success
> (which is IMHO the bug, because on next lines is the test for option
> "broken_shadow" to get success even if broken shadow record). Therefore I have
> disabled the "else return PAM_SUCCESS" code. BUT this leads into the next
> error, because spent is never initialized (see bug (2))

No, this is wrong.  If no shadow record exists for the user, there are no
authorization tasks for pam_unix to handle, and returning success here is
the correct thing to do.

If that isn't what you *want* to have happen, then you seem to have
misconfigured PAM.

> 2) there is not initialized struct spwd *spent; and if there is condition "not
> NIS and not _unix_shadowed (pwent)", then spent is never initialized, but 
> later
> it is tested in "if (!spent)" conditions. I think there is possibility, that
> the value of spent is sometimes NULL and sometimes anything else and therefore
> the conditions "if (!spent)" sometimes passed.

Of course it's not initialized, it's a local variable and the function is
returning immediately so there is no reason to waste time initializing the
variable.  That bug would only exist in your modified version of the code.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to