Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 225374 - Impossible to mount CIFS fs as normal user through mount when setuid
Summary: Impossible to mount CIFS fs as normal user through mount when setuid
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-30 07:51 UTC by Peter Åstrand
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-01-30 08:39:21 UTC

Attachments (Terms of Use)

Description Peter Åstrand 2007-01-30 07:51:41 UTC
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

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):

Comment 1 Karel Zak 2007-01-30 08:39:21 UTC
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 10:06:17 UTC
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

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.