Red Hat Bugzilla – Bug 201081
Cannot mount >1 share if shares have share-level security
Last modified: 2014-06-18 03:35:31 EDT
Description of problem: It is impossible to mount more than one share if the shares have share-level security and different passwords. Version-Release number of selected component (if applicable): Kernel 2.6.17-1.2157_FC5 How reproducible: Always Steps to Reproduce: 0. 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). 2. Now attempt to mount the second share using the mount command as well. Actual results: This will fail with an "Operation not permitted" error, and ethereal traffic will show the server responded with STATUS_WRONG_PASSWORD. Expected results: The second share should have mounted as well. Additional info: Ethereal tracing shows that this bug is occurring because the samba kernel client is sending the password of the first share for all subsequent share mount attempts. I already filed this bug in the samba bugzilla on the advice of Steve French (bug 3992), who acknowledged that it's probably a bug (the bug description there describes addtional details, including pinpointing the problem behaviour). Steve is the bugzilla owner there for cifs bugs. I'm also filing it here so that Fedora people know about it. Since Fedora made the decision to take away smbfs from the current kernels, all we're left with it is cifs, and that means currently people can only access one share at a time if they're using share-level security (please don't tell me to use user-level security; if I could, I would). That's a serious problem. I'm hoping someone at Fedora will keep an eye out on the bug in the samba bugzilla, and - once a fixed version is available (Steve promised to work on it in the next few days) - will push out a kernel with the fixed samba kernel client as soon as possible.
Can you strace both mount commands and attach the output to this bug? That will show whether the second mount command is passing the correct password to the kernel. If it isn't, it's a userspace bug in mount.cifs. If it is, it's a kernel bug, and this bug needs to be reassigned to the kernel folks.
I'll do that in a minute, Jay, but I can already tell you that's the case. If you look at the additional details in the bug on the samba site (there's a link to it in this bug), you'll see that ethereal proves that definitively.
OK, here's how I created the soon-to-be-attached strace console logs. Please note this contains my actual server address and passwords, so if one of you has the ability to change the group permissions on this bug to make it less public, I'd appreciate it (I couldn't figure out how to do that once the bug's been filed). If not, it's not a big deal: I'll change the passwords soon anyway. Jay, if this isn't what you were looking for, lemme know and I'll fix it. [root@talisker madwifi]# rmmod cifs [root@talisker madwifi]# strace mount -t cifs -o ro,password=askari01 //www.bowenjamil.com/Pictures /media/Pictures > /tmp/first_mount.txt 2>&1 [root@talisker madwifi]# strace mount -t cifs -o ro,password=askari03 //www.bowenjamil.com/Music /media/Music > /tmp/second_mount.txt 2>&1
Created attachment 133501 [details] console log of stracing the first mount
Created attachment 133502 [details] console log of stracing the second (failed) mount
Unfortunately, strace didn't follow the fork() that the mount command did before exec-ing the mount.cifs command that we're interested in. Can you re-run the tests, using strace -f ?
Created attachment 133503 [details] console log of running strace -f when running the first mount command
Created attachment 133504 [details] console log of running strace -f when running the second (failed) mount command
Argh! Now strace is truncating the line we're interested in: [pid 1633] mount("//www.{server}.com/Pictures", "/media/Pictures", "cifs", MS_RDONLY|MS_MANDLOCK, "unc=//www.{server}.com\\Picture"...) = 0 (servername redacted for security reasons.) Can you rerun it again (sigh) with strace -f -s 65536 ?
I'm getting to learn about all these options to strace I didn't know about. :) Further attachments forthcoming very shortly.
Created attachment 133507 [details] console log of running strace -f -s 65536 when running the first mount command
Created attachment 133508 [details] console log of running strace -f -s 65536 when running the second (failed) mount command
Ok. Now it's clear that mount.cifs is doing the right thing. Off to the kernel team we go. . .
OK. Thanks for helping me track that down. Please let me know if there's any other information I can provide.
Can someone on the kernel team please let me know when I can expect an update on this? Thanks!
It's been a few weeks since I last asked for an update. Anyone out there, or is this bug sitting in a black hole? Bueller? Bueller?
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I tested this with 2.6.18-1.2200.fc5. The bug is alive and well. It has exactly the same symptoms. I still need a fix, please.
I am changing the status from NEEDINFO to ON_DEV.
Steve, it's been 9 months since you acknowledged the existence/reproducibility of this bug in the samba project bugzilla. Can you please either fix it, or - if you're too busy - assign it to someone else who will fix it? Thanks! BTW, the samba bugzilla lists you with an ibm e-mail address. Is that still valid?
Hello. It's been 14 months since I opened this bug, and 5 months since the last time I asked for an update (at that time, Steve cc'ed someone at IBM about the bug, but that was it). No work has happened on this as far as I know. Can someone please let me know why this bug just keeps getting ignored?
You should be able to work around this limitation by using NAT for the connections.
I think I see what the problem may be. CIFS tries to share SMB sessions when there's an existing one, but in this case the sessions really shouldn't be shared. I'll have a look when I get some time -- this may be fixable.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening bug. I'm pretty sure this is still an upstream bug, so moving it to rawhide.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 325909 [details] patch 1 -- zero out session password on free minor cleanup/security patch
Created attachment 325910 [details] patch 2 -- change args to calc_lanman_hash the current function assumes that the password is attached to the smb session
Created attachment 325911 [details] patch 3 -- store password in tcon store the password in the tree-connect struct so that each share can use an individual password for share-level security
With these 3 patches, this now works for me. The patches here may not apply to anything but the latest upstream code, however. I've sent this to the upstream CIFS maintainer for comment. It may need some tweaking before it goes in, but should basically work. If you're able to test these patches, then let me know if they work for you.
Patchset to fix this is now upstream in Steve French's cifs-2.6 git tree. I'm going to close this with a resolution of UPSTREAM. The fix should show up in 2.6.29.