On a client running FC5 with all packages updated from
yum (running the 2.6.17-1.2157_FC5 linux kernel), I cannot
access multiple samba shares that have share-level security
0. To reproduce, use a server that serves two shares
with share-level security. Make sure the shares have
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
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
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.
Steve, please be aware that I filed this bug in the RedHat bugzilla as well:
The samba guys there made me run straces to confirm that this is not a user-space mount.cifs issue, and is indeed a kernel-level issue (the straces confirmed that mount.cifs is doing the right thing).
I wanted them to be aware of the bug so that as soon as it gets fixed, they know about it, and include the fix in the next kernel rpm they release.
To avoid having to boot an older Windows9x machine, do you remember an easy way to configure Samba for your example?
I'm sorry, Steve, but I don't. I'm using a Western Digital NetCenter external hard drive (with only consumer-grade NAS features, including no user-level security for samba shares) as the server. That drive runs 2.4.x linux and 3.0.2 samba. I have no access to its internals, including its logs or its samba configuration.
If you want, e-mail me directly at firstname.lastname@example.org, and I'll expose the two samba shares I was using to the internet for the course of your testing. I'd prefer not to because of the obvious security considerations, but if that's the only way you'll fix this bug, I'll take that chance. :)
Steve, do you still need help setting up an environment for this? My offer is still open...
I have reproduced this bug.
I don't know the right way to approach this yet - there are two obvious alternatives
1) create another smb session structure on this tcp socket for this mount (tconinfo struct)
2) try to add a password field to the tconinfo struct
I am leaning toward the former but it is not a small, trivial change and will require more thought to do right.
Steve, it's been a few weeks; any update on this?
Hi again Steve. Here's another reminder to do something about this bug. It's been sitting without activity for nearly three months now. I tested this with the latest kernel that FC5 released (2.6.18-1.2200.fc5), and the bug is alive and well.
Created attachment 2504
The last update to this bug from a Samba developer (you) occurred almost 9 months ago (when you confirmed the existence/reproducibility of the bug).
Can you please tell me why this bug is stuck in limbo?
If you don't have the time to work on it, can you please re-assign it to someone who can fix it?
Note that you're cc'ed on this bug through the redhat bugzilla as well (see comment 1 for a link to it).
Is now fixed in cifs-2.6.git and will be in 2.6.29 kernel but the patch is in multiple parts.
Has been fixed for quite a while now (although it took a big change to allow it). Please reopen if you find problems.