Simo Sorce wrote: >>3) The valadation doesn't really validate in this case since the value >>used is not what the sytem returned: \jeff != jeff, but the check in >>reply.c is only for != NULL. When this gets looked up the the samba >>password db, failure is certain. There's no \jeff in the samba password >>database. >> >> > >what != NULL case do you refer to? > > 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). 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. > > >> sesssetupX:name=[JEFF] >>[2002/08/11 12:21:44, 3] smbd/reply.c:reply_sesssetup_and_X(929) >> Using unix username \JEFF >>[2002/08/11 12:21:44, 2] smbd/reply.c:reply_sesssetup_and_X(982) >> Defaulting to Lanman password for \jeff >>[2002/08/11 12:21:44, 1] smbd/password.c:pass_check_smb(545) >> Couldn't find user '\jeff' in passdb. >>[2002/08/11 12:21:44, 1] smbd/reply.c:reply_sesssetup_and_X(998) >> Rejecting user '\jeff': authentication failed >> >> > >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. When I drop NIS and just use nss_ldap, the leading slashes can be seen in the ldap logs. [19/Aug/2002:09:05:52 -0700] conn=1922842 op=1 SRCH base="o=probes" scope=2 filter="(&(objectclass=posixAccount)(uid=\\jeff))" [19/Aug/2002:09:05:52 -0700] conn=1922842 op=1 RESULT err=0 tag=101 nentries=0 etime=0 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. > > >>4) When the client is win2k which passes a domain in, this code is >>called to lookup getpwnam(<domain><sep><user>). Without some special >>module, when would a unix system ever return a positive response to this >>kind of lookup? >> >> > >see above (if that lookup fails, username alone is tested) > 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. 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>. 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? Even if the domain came through properly, what other cases would this syntax (MP\jeff) return true on a getpwnam lookup? Jeff