On Mon, 2002-08-19 at 22:21, Jeff Mandel wrote: > In reply.c line 927 > if (sys_getpwnam(dom_user) != NULL) { > pstrcpy(user, dom_user); > DEBUG(3,("Using unix username %s\n", dom_user)); > > This call checks if sys_getpwnam is the same as the dom_user, but it > doesn't actually check the info returned from sys_getpwnam, it assumes > that if it returns at all, it must be the same. When you throw in the > winbind separator, with NIS on solaris, it seems you can get a positive > return from sys_getpwnam(\jeff).
I think this is a bug of you NIS/LDAP client, If I ask: "does \jeff exist?" and I get the reply: "yes jeff exist!" then there is a problem on the resolver not on me. > The returned value though, is not \jeff but that getpwnam string, which > should probably be parsed for the user name if a validation was to be > done. That way you know if the value returned matches the value you were > testing. > perhaps it should be something like > if (parse_user(sys_getpwnam(dom_user)) == dom_user. I cannot double check every system call, we suppose system calls work as documented (generally). > >This log seem to avail your claim, can you provide informations about > >client OS, NIS server OS, samba version .... > > > This is win98 sp2 and samba-2.2.5, solaris 8 and NIS service is provided > by padl's ypldapd agains iPlanet directory server. When ypldapd is > searching,, I can see that the request is clean: > [19/Aug/2002:09:01:35 -0700] conn=1908789 op=1583 SRCH base="o=probes" > scope=2 filter="(&(objectclass=posixAccount)(uid=jeff))" > [19/Aug/2002:09:01:35 -0700] conn=1908789 op=1583 RESULT err=0 tag=101 > nentries=1 etime=0 > > I'm guessing from this that the NIS client libraries must be cleaning up > the request before passing this along to ypldapd, though it's also > possible the ypldapd is cleaning up the request itself. Then it a problem of ypldap, have you thought to change the separator u use to say a '+' for example? > There are certainly some other possibilities with nscd in the mix, but I > think it's safe to say that there is a situation when the sys_getpwnam > unexpectedly turns up positive. It must not. > Maybe it's only in rare cases where people are using ypldapd for NIS on > solaris that these lookups can return true, but I think the real issue > is the use of the winbind separator when winbind is not in use. We may address it, but it is only a moderate performance problem (with nscd nearly uninfluent). > sys_getpwnam has only one instance in reply.c. When it gets called it's > always called with "winbind separator" "username" - never just user > name. A <null><null><user> lookup would have a better chance of sucess > then <null><separator><user>. not true, there are 2 occurences of sys_getpwnam, this is the code: /* * Always try the "DOMAIN\user" lookup first, as this is the most * specific case. If this fails then try the simple "user" lookup. */ { pstring dom_user; /* Work out who's who */ slprintf(dom_user, sizeof(dom_user) - 1,"%s%s%s", domain, lp_winbind_separator(), user); if (sys_getpwnam(dom_user) != NULL) { pstrcpy(user, dom_user); DEBUG(3,("Using unix username %s\n", dom_user)); } } /* * Pass the user through the NT -> unix user mapping * function. */ (void)map_username(user); /* * Do any UNIX username case mangling. */ smb_getpwnam(user, True); ^^^^^^^^^^^^^^^^ smb_getpwnam inside calls sys_getpwnam and pther stuff. > This is why I'm wondering if winbind is not in use, why this test is > done this way. Without winbind, when would you use a winbind separator? lazyness I think, I'll see if I can arrange a test before the calls. > Even if the domain came through properly, what other cases would this > syntax (MP\jeff) return true on a getpwnam lookup? never, only if winbind is in use. -- Simo Sorce - [EMAIL PROTECTED] Samba Team - http://www.samba.org