FIX: NT sending null username effects %U expansion

[thwartedefforts at wonky.org]

On Mon, 26 October 1998, Luke Kenneth Casson Leighton wrote:

> hi, yes it does make a difference.  docs are being updated this week.  the
> only "proper" fix is to deny all anynomous connections, causing clients to
> send username / password instead.
> 
> this will break things, unfortunately.  it was the original "NT 3.1" and
> "NT 3.5" model, which microsoft deliberately brok in " NT 4.0".
> 
> luke

I understand that.  But this doesn't explain the explict copy of user to
 sesssetup_user because that second if will _always_ succeed.  I propose the
 following patch to that second if in smbd/reply.c (against cvs 981026):

*** smbd/reply.c.orig   Tue Oct 27 09:28:39 1998
--- smbd/reply.c        Tue Oct 27 09:28:55 1998
***************
*** 597,603 ****
     * working.
     */
  
!   if((lp_security() != SEC_SHARE) || *user)
      pstrcpy(sesssetup_user,user);
  
    reload_services(True);
--- 597,603 ----
     * working.
     */
  
!   if(((lp_security() != SEC_SHARE) || *user) && !guest)
      pstrcpy(sesssetup_user,user);
  
    reload_services(True);

This change will make sesssetup_user be the same as user _only_ if samba is
 not implictly forcing guest access when the client passes a null
 username/password.  I've tested this and am unable to reproduce the effect I
 originally described. This also makes non-null sessions override each other
 thereby changing what %U expands to and reading a different configuration file
 if a different username is used -- I believe this is wanted effect.

But, I still don't know how that is going to change the intended effect on
 share level security (although, I suspect not at all, seeing as how usernames
 are useless in share level security, and thus the value of %U is
 useless -- correct?).

If this doesn't fall under "proper" fix, or even close to it, can someone
 please explain why?

Dave Andruczyk, could you try this out and see if it fixes your problem?
 Rereading your description makes me think it might, but I'm unable to
 figure out exactly where your problem lies -- it maybe outside the scope of
 implict guest access.

References:
  Original description of problem:
    http://samba.anu.edu.au/listproc/samba-ntdom/2264.html
  Note of always true condition in smbd/reply.c
    http://samba.anu.edu.au/listproc/samba-ntdom/2289.html
  Dave's related(?) problem:
    http://samba.anu.edu.au/listproc/samba-ntdom/2272.html

Andy.
thwartedefforts at wonky.org