NT sending guest username and parameter parsing problem

[thwartedefforts at wonky.org]

I'm experiences two problems.

First (the more serious one).  I experienced this with cvs from 981020.

NT Workstations (SP3) seem to be sending 'guest' as the username at times when requesting a list of shares.  This makes the %U parameter mostly useless.  Take the following example (please!):

smb.conf:
   include = /shares/perms/user.%U
   [everyone]
      blah blah

   [homes]
      blah blah

/shares/perms/user.abakun:
   [share1]
      blah blah

   [share2]
      blah blah

Note that samba is configured to be the domain controller (Everything works; loging in, profiles, logon script, password change (from my initial tests at least)).  When I login as abakun, I should see the following shares:

  abakun
  everyone
  share1
  share2

Right?  When I browse the samba machine, I see these.  But sometimes, when I click on share1 or share2, it will tell me that name \\server\share1 couldn't be found, and doing a refresh of the share listing in the explorer window removes share1 and share2.  Looking in the debug logs shows that the username that was sent was 'guest', and sometimes I'll see a message to the effect that it couldn't find the file named /shares/perms/user.guest when it checks to reread the configuration files.  Now what is interesting is that if I access my homes share first (\\server\abakun) then share1 and share2 seem to stick, but if I access everyone, share1 or share2 before I access \\server\abakun, it seems to go into an unpredictable state whereas I can't determine if my workstation is going to sent 'guest' as the username or the name I actually logged in as when it sends future requests for the share list.  I believe this can be forced to happen in a more predictable way if you have guest only shares which are accessed before shares that require validation.

Has anyone else noticed this?  I was first experiencing this problem when half my machines where in one domain and half were in another, and I figured that once a machine was loging into a domain, and from then on is validated to use resources in the domain, the workstation would consistantly send the entered/validated username for the life of the logon.  Now that the only domain that exists is the samba controlled domain, I'm still seeing this behavior.

Perhaps there could be a work around in samba, where if a user is logged into the domain, and was previously validated, that username could be used even if the workstation sends guest as the username -- if I remember correctly, the workstation may be sending a null username, and samba is defaulting to guest in that case.  I'll have to take a look at the code to verify this, if I can remember where in the code I first saw that happening (I'm still getting familar with the samba code).



Second (the less serious one).  I experienced this with alpha7.

I was trying to configure a custom print command in a printer share, and I had a line similar to the following:

  print command = /usr/local/bin/doprint %s %p %M "%U"

(quotes around %U because some usernames contained spaces)  And it was always failing, never even executed doprint.  The debug log showed that executing the command was returing 512 (which I figured out later was the result of bash giving a parse error on the command -- this seems to be undocumented in the bash man page).

Turns out that when it reads the conf file, it is explictly removing trailing quotes, so it was trying to execute:

  /usr/local/bin/doprint %s %p %M "%U

which voilates shell quoting rules.  I fixed this by rearranging the parameters (and thusly changing doprint :) ) so that the parameters I wanted quoted appeared earlier and a non-quoted one appeared last.

Quoting from John Blair's Samba book (page 109):

  Remember that no quotation marks are ever needed.  However, for convience,
  if leading and/or trailing quotation marks are found, they will be dropped.

The effects of leading and trailing quotation marks are not mentioned in the man page, except to say that they are not needed.
So yeah, this is my fault -- I should have used single quotes (which I think would fix it, since samba only removes double quotes?), but this seems inconsistant.  A trailing quote should only be removed if there is a leading quote (after the equal sign).  Internal quotes are kept (for passing onto the shell), which is important for things like the preexec and print command parameters.  What about internal whitespace in the user map file (where you need to use quotes around multi-word values).  What kind of action should happen here?  I think I can whip up a patch to make it behave like *I* think it should, but that might not be the right thing (and might break someone's conf file).

Andy.