|Summary:||net-fs/mount-cifs ebuild prevents non-root users using mount.cifs|
|Product:||Gentoo Linux||Reporter:||Gerard Neil <xyzzy>|
|Component:||New packages||Assignee:||Gentoo Linux bug wranglers <bug-wranglers>|
|Package list:||Runtime testing required:||---|
Description Gerard Neil 2008-02-15 12:16:49 UTC
When mount.cifs used to be installed as part of samba, it was installed setuid. This allows non-root users to mount cifs shares as described in the man 8 mount.cifs. Since the split from samba into net-fs/mount-cifs, it isn't installed setuid anymore. I don't know if this is part of some general policy about not installing anything setuid by default, but it would help to at least have a USE flag to control this. Reproducible: Always Steps to Reproduce: Attempt to mount any cifs share as non-root user gets "operation not permitted" monkey ~ $ sudo chmod u-s /usr/bin/mount.cifs monkey ~ $ mount.cifs //goblin/gid @goblin Password: mount error 1 = Operation not permitted Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) monkey ~ $ sudo chmod u+s /usr/bin/mount.cifs monkey ~ $ mount.cifs //goblin/gid @goblin Password: monkey ~ $ #success!
Comment 1 Jakub Moc (RETIRED) 2008-02-15 14:25:18 UTC
*** This bug has been marked as a duplicate of bug 186383 ***
Comment 2 Gerard Neil 2008-02-18 06:15:25 UTC
I don't believe this is a duplicate of 186383. Bug 186383 refers to being unable to mount as a non-root user EVEN IF /usr/bin/mount.cifs is setuid. That's not the problem here; in this case, the problem is that /usr/bin/mount.cifs is NOT INSTALLED setuid by the ebuild. Up to ebuild samba-3.0.24, if you installed samba, you got /usr/bin/mount.cifs setuid. You can see where this happens in the build: unpack samba-3.0.24-r3 and look at source/Makefile.in:143: the line is SUBIN_PROGS = @CIFSMOUNT_PROGS@ @EXTRA_SUBIN_PROGS@. But the later samba builds have removed this, and appear not to install mount.cifs setuid. Perhaps net-fs/mount-cifs ebuild was created post 3.0.24, and that's why the new ebuild doesn't install mount.cifs setuid. I don't know. BUT in any case, the problem is this: I want /usr/bin/mount.cifs installed setuid, and I don't want to have to remember to do it myself every time mount-cifs gets emerged. That's why I'm suggesting that there should at least be a USE flag. (And BTW, bug 186383 states that the mount command checks permissions on the /sbin/mount.cifs symlink and not on /usr/bin/mount.cifs. This simply isn't true. The stat64("/sbin/mount.cifs",...) will dereference the link. You have to use lstat64() to check permissions on the link itself. My original description shows this is true; I really don't know what's up with that other bug, but it doesn't matter anyway).
Comment 3 Jakub Moc (RETIRED) 2008-02-18 07:22:23 UTC
Well as noted on the other bug, if you dislike this, you need to take it upstream; suid doesn't fix anything here either. *** This bug has been marked as a duplicate of bug 186383 ***
Comment 4 Gerard Neil 2008-02-18 11:24:01 UTC
(In reply to comment #3) > Well as noted on the other bug, if you dislike this, you need to take it > upstream; If I dislike what? > suid doesn't fix anything here either. No, that's not true. setuid DOES fix the problem... look at my original description. Perhaps the information in the other bug is out of date. setuid fixes the problem for me now, and has since the very first release of net-fs/mount-cifs. > *** This bug has been marked as a duplicate of bug 186383 *** ... and that's why this isn't a duplicate.
Comment 5 Jakub Moc (RETIRED) 2008-02-18 13:38:56 UTC
(In reply to comment #4) > No, that's not true. setuid DOES fix the problem... look at my original > description. Perhaps the information in the other bug is out of date. setuid > fixes the problem for me now, and has since the very first release of > net-fs/mount-cifs. Well it clearly doesn't, as noted on bug 186383 Comment #1, bug 186383 Comment #2 and multiple duplicates thereof. Marking as UPSTREAM since you apparently can't live with DUPLICATE.
Comment 6 Gerard Neil 2008-02-19 06:40:46 UTC
> Well it clearly doesn't, as noted on bug 186383 Comment #1, bug 186383 Comment Maybe it didn't fix it for you when you last tested. But it fixes the "operation permitted error" for me now, and it has done so ever since net-fs/mount-cifs was split from samba, I've been doing chmod u+s /usr/bin/mount.cifs each time. I have never had any problem with symlinks, which is the subject of the other bug. > #2 and multiple duplicates thereof. Please look harder at these duplicates: Bug 194799 - mount.cifs from net-fs/mount-cifs-3.0.25c doesn't allow non root > > chmod +s /usr/bin/mount.cifs > and > chmod +s /usr/bin/umount.cifs > helps. ... so setuid fixes the problem Bug 192379 - mount.cifs not installed setuid by net-fs/mount-cifs-3.0.25c > Since the mount.cifs program was split off from the core samba package, > it is no longer installed setuid, meaning non-root users can no longer > mount Samba shares regardless of permissions and other settings ... implicitly, if it IS installed setuid then the problem goes away > Marking as UPSTREAM since you apparently can't live with DUPLICATE. You're being combative. This is about two issues being confused. Please stop to consider and answer my points instead.
Comment 7 Ryan Tandy 2008-02-19 19:48:00 UTC
From the man page for mount.cifs(8): The mount.cifs utility attaches the UNC name (exported network resource) to the local directory mount-point. It is possible to set the mode for mount.cifs to setuid root to allow non-root users to mount shares to directories for which they have write permission. So regardless of any actual bugs affecting the issue (for me, at least, marking the binary setuid does work as advertised), I believe the wording here implies that the choice of whether to mark the binary setuid is up to the local system admin, and therefore should not be setuid by default. My preferred solution would be a USE flag, 'suid' perhaps, so that Portage knows about the changed mode; a note in the ebuild that the mode needs to be manually changed to enable mounting by non-root users would also be acceptable.