Hide Forgot
Description of problem: At our site we use CIFS for home directories and kerberos for mounting them. Basically root runs a command similar to the following: # mount -t cifs -o nobrl,suid,exec,mapchars,mfsymlinks,noserverino,file_mode=0700,dir_mode=0700,user=johndoe,uid=12345,cruid=12345,gid=12345,sec=krb5 //server/johndoe /mnt/johndoe The 'exec' mount option is always ignored and the share is mounted noexec. For home directories this is pretty inconvenient if you have your own software in there. The mount command should be changed in a way that root can actually mount a directory with the 'exec' mount option. Version-Release number of selected component (if applicable): kernel-3.5.3-1.fc17.x86_64 cifs-utils-5.6-1.fc17.x86_64 How reproducible: Always. Steps to Reproduce: 1. Set up a Samba server with kerberos authentication 2. Add a user 'johndoe' 3. Try to mount the share 'johndoe' as root using a command line similar to the one above. Actual results: Share is mounted 'noexec' Expected results: Share should be mounted 'exec' since the command is run by root. Additional info: The same mount command line works fine on our RHEL 6.X systems. In the man page of mount.cifs it says (also note the typo): This command may be used only by root, unless installed setuid, in which case the noeexec and nosuid mount flags are enabled. We do not have the suid bit set though: # ls -la /sbin/mount.cifs -rwxr-xr-x. 1 root root 36552 Jul 26 17:43 /sbin/mount.cifs
We can chalk this one up to bad documentation. The problem is is the user of 'user=' as a mount option which confuses /bin/mount into thinking that this is a non-superuser mount. It then adds a number of mount options to nerf this mount (including noexec). If you change that option to read "username=johndoe" then it should work just fine. I've proposed a patch upstream to clarify this in the mount.cifs manpage: http://article.gmane.org/gmane.linux.kernel.cifs/7039 ...it should make the next release assuming no one complains.
Also, cc'ing Karel Zak. Is the above a regression in /bin/mount? Should it be treating the "user=" option differently from "user"?
With 'username=...' it works like a charm. Thanks a lot for the quick response!
(In reply to comment #2) > Also, cc'ing Karel Zak. Is the above a regression in /bin/mount? Should it > be treating the "user=" option differently from "user"? This problem should be already fixed in f18 and upstream: commit e90e7401d0c318c9dac4a0204e2bca86949b1d32 Author: Karel Zak <kzak@redhat.com> Date: Thu Jun 14 14:19:26 2012 +0200 libmount: don't use nosuid,noexec,nodev for cifs user=foo .. if you want to see it backported to f17 then clone/reassign this bug to util-linux. Thanks.
Nah, I think it's ok. I'll just plan to pull in the documentation patch for cifs-utils soon and take it from there.
Manpage patch pushed to mainline. I'll plan to pull it into f17 once I cut a new upstream release, which should be real soon now...
cifs-utils-5.7-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/cifs-utils-5.7-1.fc17
Package cifs-utils-5.7-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cifs-utils-5.7-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15827/cifs-utils-5.7-1.fc17 then log in and leave karma (feedback).
cifs-utils-5.7-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.