Bug 225374 - Impossible to mount CIFS fs as normal user through mount when setuid
Impossible to mount CIFS fs as normal user through mount when setuid
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-30 02:51 EST by Peter Åstrand
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-30 03:39:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Åstrand 2007-01-30 02:51:41 EST
Description of problem:

The mount.cifs program is designed so that ordinary users should be able to
mount, when setuid. It works great:

$ /sbin/mount.cifs //samba/astrand /home/astrand/cifshome

However, as I understand it, it's preferrable to use "mount -t cifs" instead.
The mount.cifs man page, for example, says:

"mount.cifs mounts a Linux CIFS filesystem. It is usually invoked indirectly by
the mount(8) command when using the "-t cifs" option."

But, this does not work for ordinary users, even when both mount and mount.cifs
are setuid:

$ mount -t cifs //samba/astrand /home/astrand/cifshome
mount: only root can do that

If I *remove* the setuid bit from mount, then it works correctly:

$ mount -t cifs //samba/astrand /home/astrand/cifshome
Password:

You can notice the same thing by running mount through strace, since this
disables setuid. I believe this is a very strange behaviour. 

If this is, after all, the correct behaviour of the mount command, then why are
mount.cifs and umount.cifs (only) located in /sbin - a directory that most users
don't have in PATH? 

Version-Release number of selected component (if applicable):
util-linux-2.13-0.45.4.fc6
Comment 1 Karel Zak 2007-01-30 03:39:21 EST
Yes, this is the correct behavior of the mount command.

You have to fully specify mount options in fstab when you want to use it as
non-root user. The mount usage for standard users is very restricted (because
sbit) and they can use the mount command only if there is mount point definition
in the fstab file -- things like -t or -o are forbidden.

See "man mount" and the "user/users" options. You need to add to your fstab
something like:
 
  //samba/astrand /home/astrand/cifshome  cifs  users


  

Comment 2 Peter Åstrand 2007-01-30 05:06:17 EST
Using entries in fstab is not acceptable in our case, with possibly hundreds of
simultanious users on the same machine. 

This might not be a bug, but it's at least a lack of feature. I've found another
workaround in addition to strace:

$ cp /bin/mount /tmp/
$ /tmp/mount -t cifs //samba/astrand /home/astrand/cifshome

Surely there must be a more elegant way of solving this. If all else fails, we
could introduce a command line option to mount for dropping root access directly
after start. 

My gut feeling is that the real problem here is that the protocol between the
mount command and the external helper is too vague wrt to root and setuid stuff. 
The man-page for mount doesn't say anything at all about the protocol. The
umount-man-page, though, is a little bit more detailed:

       The syntax of external umount helpers is:

       /sbin/umount.<suffix> [-nlfvr] dir | device

       where the <suffix> is filesystem type or a value from "uhelper=" mtab option.

       The uhelper (unprivileged umount request helper) is possible used when
non-root user wants to umount a  mount-
       point which is not defined in the /etc/fstab file (e.g devices mounted by
HAL).

It seems like someone has given a thought about this at least for the umount
case. But, it doesn't work: umount has the same problem as mount. 

Note You need to log in before you can comment on or make changes to this bug.