samba - Aug 2006 - Bug in kernel-space samba client (3.0.23a) on FC5 (2.6.17-1.2157_FC5)

On a client running FC5 with all packages updated from
yum (running samba 3.0.23a-1.fc5.1 and the
2.6.17-1.2157_FC5 linux kernel), I cannot access
multiple samba shares that have share-level security
using cifs.

0.  To reproduce, use a server that serves two shares
with share-level security.  Make sure the shares have
different passwords.

1.  Using the standard mount command and specifying
cifs as the fs, mount the first share (it doesn't
matter which one you pick).  

If you watch the ethereal traffic, pay attention to
(what I presume is the encrypted form of) the password
that gets sent as part of the TreeConnect AndX Request
packet.  Let's call this hexadecimal password string
"A".

2.  Now attempt to mount the second share using the
mount command as well.  This will fail with an
"Operation not permitted" error, and ethereal traffic
will show the server responded with
STATUS_WRONG_PASSWORD.  

If you watch the ethereal traffic closely, you'll
notice that no matter what password you try to send
for this second share, the client software sends
string "A" (which - as previously mentioned - is the
password for the first share) to the server in the
TreeConnect AndX Request packet, and thus the server
correctly rejects the password.

This is clearly a bug in the samba 3.0.23a
kernel-space client.

Can someone let me know if this has already been
identified and even fixed in 3.0.23b?

In case you're interested, here's some more info...

Here's a log of my console:

[root@talisker madwifi]# mount -t cifs -o ro //[MY
SERVER]/Pictures /media/Pictures/
Password:
[root@talisker madwifi]# mount -t cifs -o ro //[MY
SERVER]/Music /media/Music/
Password:
mount error 1 = Operation not permitted
Refer to the mount.cifs(8) manual page (e.g.man
mount.cifs)

Note, in this example, the first mount (for the
'Pictures' share) worked, but the second one failed.

If I restart my client machine, and access the 'Music'
share first, then that one will successfully mount,
but the 'Pictures' share won't.

The only information in /var/log/messages is:
Jul 31 15:48:33 talisker kernel:  CIFS VFS: cifs_mount
failed w/return code = -1

Echoing 1 into /proc/fs/cifs/cifsFYI produces no more
output in the log (this used to work in FC3 - how does
one produce more debugging data now?).  Disabling
linux extensions doesn't change the behaviour.

I will add that this is an improvement over the result
on my FC3 machine, where even one share cannot be
mounted using cifs.  In a previous e-mail to the samba
list where I was primarily dealing with another issue,
I said that running ethereal showed in that FC3 case
that the share password wasn't being correctly sent at
the same time as the TreeConnect AndX Request for the
share (the client in that case only sent '00' as the
password).  The server thus responded with
STATUS_WRONG_PASSWORD.

In the FC5 case, ethereal shows what appears to be the
encrypted form of a password (albeit the incorrect
one) being sent when the TreeConnect AndX Request
packet gets sent.  So, at first glance, it appears
that at least the password sending bug got fixed in
the newer version of the samba client (unfortunately,
it only got partially fixed).  The server
unfortunately responds with STATUS_WRONG_PASSWORD for
the reason mentioned above.  

Accessing both shares through the user-space smbclient
program works just fine.  



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

On Tue, Aug 01, 2006 at 05:25:25PM -0700, samba newbie
wrote:
> On a client running FC5 with all packages updated from
> yum (running samba 3.0.23a-1.fc5.1 and the
> 2.6.17-1.2157_FC5 linux kernel), I cannot access
> multiple samba shares that have share-level security
> using cifs.
> 
> This is clearly a bug in the samba 3.0.23a
> kernel-space client.
FYI: The CIFSFS kernel client is developed independently
of Samba, so Samba version numbers like 3.0.23a mean
nothing to cifsfs mounts - they are known by kernel
version numbers, not Samba version numbers.
> Can someone let me know if this has already been
> identified and even fixed in 3.0.23b?
See above. Having said that I'm not sure how much
testing Steve does with share level security. I'll
forward your message on to him.
> Accessing both shares through the user-space smbclient
> program works just fine.  
The smbclient program is part of Samba, so it's
fair to use Samba version numbers like 3.0.23a
for that :-).

Jeremy.