Re: Prepending \ to user name w/Win98 Domain Login

2002-08-19 Thread Jeff Mandel

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(domainsepuser). 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 nullnulluser lookup would have a better chance of sucess 
then nullseparatoruser.

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




RE: Prepending \ to user name w/Win98 Domain Login

2002-08-18 Thread Simo Sorce

I've just looked at the code, and it retest later with username only if
it has not got access with the domain name set, so I see no problems at
all. Can you provide more informations eventually? 

On Fri, 2002-08-16 at 17:21, Jeff Mandel wrote: 
[snip]
 This call supposedly validates the domain\user string.
 On Solaris, with NIS a win98 box tries to connect to a samba PDC. 
 There's no domain name passed by the win98 client, but the setup for the 
 string is domainwinbindseparatoruser.

look a few lines later it does another sys_getpwnam() with user name
only. 
 
 There's no domain - the string is now \user
 1) If there's no domain, why would a winbind separator do something useful?

see above 

 2) The wacky thing here is that \user actually returns successful with NIS.
 jeff@host% getent passwd jeff
 jeff:x:6789:6789::/export/home/jeff:/bin/ksh
 jeff@host% getent passwd \jeff
 jeff:x:6789:6789::/export/home/jeff:/bin/ksh

this test is not right you should write \\jeff to check if NIS really
ignores a leading \ because \ is an escape and the shell will interpret 
\j as pure j 


I've just setup a linux NIS server and couldn't reproduce this bug, BTW

 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? 

   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 

 4) When the client is win2k which passes a domain in, this code is 
 called to lookup getpwnam(domainsepuser). 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)

Simo.

-- 
Simo Sorce - [EMAIL PROTECTED]
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-- 
Simo Sorce - [EMAIL PROTECTED]
Samba Team - http://www.samba.org



RE: Prepending \ to user name w/Win98 Domain Login

2002-08-16 Thread Mike Gerdts

On Fri, 2002-08-16 at 11:21, Jeff Mandel wrote:
 2) The wacky thing here is that \user actually returns successful with NIS.
 jeff@host% getent passwd jeff
 jeff:x:6789:6789::/export/home/jeff:/bin/ksh
 jeff@host% getent passwd \jeff
 jeff:x:6789:6789::/export/home/jeff:/bin/ksh

Not quite right.  Your shell handled the \j and determined that it
should have just been j.  As such, the getent command really saw
jeff, not \jeff.  The proper test would have been

   jeff@host% getent passwd \\jeff

In this case your shell would have translated \\jeff into \jeff
before sending it as an argument to getent.

Mike




Re: Prepending \ to user name w/Win98 Domain Login

2002-08-16 Thread Jeff Mandel

While that was an example of how it returns with NIS, a better one might 
have been to show the lookup quoted  - like ypmatch \jeff passwd, 
but I agree the escaping can be confusing and misleading with the shell 
there.

The log files excerpts and ldap lookups weren't done by shell, per se, 
but by smbd. How would the shell come into play in those instances?

Jeff

Mike Gerdts wrote:

On Fri, 2002-08-16 at 11:21, Jeff Mandel wrote:
  

2) The wacky thing here is that \user actually returns successful with NIS.
jeff@host% getent passwd jeff
jeff:x:6789:6789::/export/home/jeff:/bin/ksh
jeff@host% getent passwd \jeff
jeff:x:6789:6789::/export/home/jeff:/bin/ksh



Not quite right.  Your shell handled the \j and determined that it
should have just been j.  As such, the getent command really saw
jeff, not \jeff.  The proper test would have been

   jeff@host% getent passwd \\jeff

In this case your shell would have translated \\jeff into \jeff
before sending it as an argument to getent.

Mike