Thank you for your answer.

On Wed, 25 Apr 2007, Steve Langasek wrote:

> 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.

*** OK. I think I understand the idea just now. I will use pam_access, it looks 
as better solution. Thank you.

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

*** The problem is that libnss-ldap version from Sarge returns line:

wolf:x:10001:100:Robert Wolf:/home/wolf:/bin/bash

and "x" means shadow.

But libnss-ldap from Etch returns line

wolf:*:10001:100:Robert Wolf:/home/wolf:/bin/bash

and "*" means "no password"(?) Or does it mean anything else? Is it the bug in 
libnss-ldap?

I have a userPassword attribute in LDAP server, but the anonymous user (and any 
other user except directory manager) cannot read it, it is possible only to 
bind with password. Is it correct that libnss-ldap returns "*" when it cannot 
see/read userPassword attribute?

Regards,

Wolf.


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

Reply via email to