Bug in handling '\\server\service%username'

[Peter Daum]

Hi,

I was experimenting (without success) with the
"\\server\service&username" method to specify a username.
Meanwhile I found out, why it isn't working. I am fairly
confident, that it wouldn't be hard to fix, but I personally am
not familiar enough with samba's data structures to do it. Here
is, what I found so far:

The problem:
Windows 9x insists on using one single username for all smb
connections, thus making it almost impossible to connect to a
system, where Windows' primary user name is not valid (or at
least no valid for the current user).

Let's assume, that a user is logged on to his Windoze box (and
possibly to some PDC, other SMB servers, whatever) as user "foo".
No he is trying to connect to connect to a share on a Samba
server, where he has a valid user account, but unfortunately
under the name "bar". So he enters "net use \\SRV\share%bar".

In Samba, (reply.c/reply_tcon_and_X) the string is correctly
parsed as a connection request of user "bar" to share "share".
The value for "vuid", however, is initialized from "inbuf"
(containing, I suppose, the message, that Windows sent). Then
"make_connection" is called with vuid as an argument.

make_connection (service.c) does all kinds of neat stuff
(authentification against the supplied username "bar", for
example) and eventually calls become_user (uid.c), again passing
on the supplied "vuid". This is mapped back to a username (the
username that windows sent "foo" in our case) and in
check_user_ok validated, whether the user is allowed to connect.
In the example, this will even though the authentification for
"bar" was successful, this will lead to denying access, because
"foo" is not a valid user on our system.

Maybe the easiest solution would be, to just patch the (user
supplied) username into the received message as soon as it is
noticed (in reply_tcon/reply_tcon_and_X) and just pretend,
overwriting the (invalid) username that windows sent. Would this
be feasible?

It would be great, if that problem could be somehow solved; the
"\\server\service&username" syntax seems to be most feasible way
to work around the limitations of Win9x as a network client.

Regards,
                 Peter Daum