macro subsitution inconsistancies

thwartedefforts at thwartedefforts at
Thu Aug 20 16:20:34 GMT 1998

I'm having a problem with 1.9.18p7 (and I've checked the sources for 1.9.18p8 and the ntdom branch also, so I suspect the problem exists for those builds also).

I want to have certain shares show up and configurations happen depending on the user name, so I've defined parameters in /etc/smb-confs/smb.conf.USERNAME, like so:

     blah = ...
     blah blah = ...

and in my /etc/smb.conf file, I have:

  include = /etc/smb-confs/smb.conf.%U

in the [global] section.  Now, according to the man page, the book by John Blair, and other stuff, %U is the username that NT sends for the session, and it is always defined (unlike %u, which is only defined in a share context, but I didn't need to tell you that :) ).  This works great, does exactly what I want, the first time I open up the samba machine from the NTWKS (SP3, btw), but if I open the onlyabakun share, it says it doesn't exist, and if I traverse into a share that everyone has (that is, defined directly in the /etc/smb.conf file), then refresh the share list, the shares I defined in the include file disappear.

I tracked this down, using the debugging output, to the fact that NT sends the username when getting the share browse list the first time. The debug log has in it


but later on, when the browse list is requested again, NT apparently DOES NOT send a username, even though it is using the same connection that was initially authorized.  The debug log shows:


Looking at the sources, I tracked this down to reply.c:reply_sesssetup_and_X, which contains this code and comment:

  /* If no username is sent use the guest account */ 
  if (!*user)
      /* If no user and no password then set guest flag. */
      if( *smb_apasswd == 0)
        guest = True;

This makes sense, considering that it then tries to read the file /etc/smb-confs/smb.conf.guest (my guest account = guest).

I don't know if this should be chalked up to a bug in NT (not sending a username to get a browse list on subsequient requests unlike how it does the first time) or a samba bug implictly using the guest account even though that connection has  already been auth'ed.  As such I'm not sure of a "correct" solution.  Note that I was unable to reproduce this with smbclient, I think because smbclient sends the username you specify and doesn't do crazy things like "rerequest the share list without a username".  Of course, I'm able to get my different configurations to show up with smbclient and a specified username (this confirms that my %U dependent conf files are being read correctly), so this is specific to the client being NT (perhaps win95, I havn't tried with other MS clients)

Admittedly, I've only been looking closely at the samba source code for about two weeks so I might be way off.  Perhaps the above assignment to the user variable could be:


with the intended effect of keeping the values of %U and %G usable (just below the above code, there is a comment about share level security and an apparent workaround to keep %U and %G working, so this might not be without precedent). How this effects security in general, I don't know.

That is, if what I understand about where %U's and %G's values come from -- like I said, I might be way off.

Andy Bakun
thwartedefforts at

More information about the samba mailing list