null session %U expansion (patch)

[thwartedefforts at wonky.org]

On Fri, 30 October 1998, Jeremy Allison wrote:

> Sorry about that - I've been just a bit busy...

Understandable.

> The cases we need to look at here are, firstly security=share.
> This is the case that the sesssetup_user global was created
> for - it keeps the last used username around as with share
> level security you have no vuid's in an smb packet to 
> determine the user.

Note that my patch treats security=share independantly of the
other security levels, always giving the original behaviour in
this case, no matter what the values of the new parameters.

> With all other 'security=' levels every packet contains
> a valid vuid number which is checked before access is
> allowed.

I'd like to verify this myself (not that I don't trust you, just
that I want to fully understand).  Unfortunately, I don't think
it will apply anyway, because in reply_sesssetup_and_X, the vuid
stuff isn't used in the place where it's assigning to 
sesssetup_user.  Perhaps it should be.

> As a part of that check the client user name that was 
> authenticated to produce that vuid is copied into the
> sesssetup_user global to ensure that %U macro expansion
> works correctly in the context of that smb request.
> 
> The only issue is when a null sessionsetupandX is sent.
> This will create a valid vuid, but currently sets the 
> authenticated user name to the UNIX user designated as
> the Samba 'guest' account, instead of a blank string.
> 
> That this means is that all %U macro expansions done
> when an SMB request with this vuid comes in will map
> to the Samba UNIX 'guest' user, rather than become blank.
> 
> All we need to decide is if this is desired behaviour,
> and if not, what username we want to use for %U macro
> expansion for an anonymous connection.

Is this connection really anonymous?  It was previously
validated, and it is the same connection.  The behaviour
of the client I'm seeing is that I
open up in Window's Explorer my samba machine.  I click
on a share.  The share's contents show up, and then between
2 and 5 seconds later, the share contents refresh _without_
user intervention, and apparently reply_sesssetup_and_X is
being called again, but with an empty username.  This
effects the reload_services call, and the names of the 
configuration files it subsiquently reads.  It seems this
only happens once, no matter which share I open.  If
I open a second share, the client doesn't end up invoking
reply_sesssetup_and_X again.

This is all using NT4SP3 client.  I observe the same thing
(refresh) when I connect to a NT4SP3 Server, rather than 
samba, although it doesn't actually do anything because
you can't configure NT Server to have different 
configurations based on user.

> My argument would be that the current behaviour, which
> is to use the Samba UNIX 'guest' name, is the correct one
> and then document it.

I would agree if this was occuring over a competely new 
connection, but my tests show that it's not.  The connection
is previously validated, which is proven(?) by the value of
sesssetup_user that is being overwritten.

> If you don't think it's desired behaviour then what name
> to do want %U to map to when SMB packets come in that
> are from an anonymous session ?

If it's from a previously validated session, I want %U to
not change (keep it's previous value).  If it's a completely
new connection that is anonymous, then the specified guest
user.

Also, I notice that reply_sesssetup_and_X is doing the 
guest account detection and assignment, but then it goes 
on to call map_username.  Isn't the mapping to the guest 
account the same as mapping to any other unix user?

Andy.