On Sun, Jul 08, 2007 at 03:50:58PM -0700, Steve Langasek wrote:
> > [EMAIL PROTECTED]:~$ smbmount //frodo/ianma ~/tmp -o uid=ianma,gid=users
> > Password:
> > [EMAIL PROTECTED]:~$ ls -la ~/tmp
> > total 24
> > drwxr-xr-x 1 root root 4096 2007-07-05 09:12 .
> > drwxr-xr-x 68 ianma users 4096 2007-07-04 16:28 ..
> > -rw------- 1 1039 users 99 2007-06-15 13:20 .bash_history
> > -rw-r--r-- 1 1039 users 220 2006-12-12 08:20 .bash_logout
> > -rw-r--r-- 1 1039 users 414 2006-12-12 08:20 .bash_profile
> > -rw-r--r-- 1 1039 users 2227 2007-06-15 13:19 .bashrc
> > drwxr-xr-x 1 1039 users 0 2007-06-15 13:20 .mc
> > [EMAIL PROTECTED]:~$
> > (Note: user 1039 is the uid for "ianma" on the remote Samba server)
> Thanks, this makes it pretty clear to me what's going on.
> First of all, from a security perspective, it's important that the suid-root
> mounting script (smbmount+smbmnt) not be usable by the mounting user to
> gaing privileges he doesn't otherwise have. This /possibly/ means that the
> user should not be allowed to specify arbitrary uid,gid settings when
> mounting. It also *definitely* means that the user should not be able to
> use smbmount to mount filesystems with full Unix extensions -- you do *not*
> want a user to have a copy of /dev/hda that they own, or a copy of /bin/sh
> that's suid root!
> Now, it looks like the current behavior of smbmount is a result of the added
> patch, missing_userspace_bugzilla999. If I drop this patch from samba
> 3.0.25b-1 and rebuild, the resulting smbmount gives me mounts with the
> current user's uid, regardless of server permissions and regardless of uid
> options passed on the commandline.
> So it looks like a bug in this patch. I'll try to see what's up with it.
Ok, it's straightforward to make smbmnt always mount filesystems with
uid=getuid() when called as non-root. I've adjusted the new
missing_userspace_bugzilla999.patch to do just this, and will commit the
change soon to the Debian repository.
A few other things I've noticed along the way:
- smbmnt always mounts devices nosuid,nodev regardless of how smbmnt is
called and regardless of whether Unix extensions are present, so the
security problem was a false alarm on my part.
- mount.cifs also always mounts devices nosuid,nodev when called as
non-root, but uses the defaults (suid,dev) when called as root, which is
a step better than smbfs.
- the same bug of a non-root user mounting a share from a server with Unix
extensions, and not having access to the files because of the mapping of
Unix file permissions, exists in mount.cifs as well.
- the permissions options are ignored by mount.cifs when talking to a Samba
server, even when called by root; so root has no control at all over the
permissions with which the files are exposed.
- umount.cifs can be called as non-root to unmount a share mounted by the
same user, but it seems to not always work ('Permission denied'), seems to
not always remove the entry from /etc/mtab, and seems to allow unmounting
by a user other than the user who originally mounted the device. The
first two problems are no longer reproducible for me, so maybe they were
only in 3.0.24 (I can't downgrade at the moment to check), but the third
is consistently reproducible for me with 3.0.25b.
Upstream has long since abandoned smbfs in favor of cifs, and there has been
talk of dropping smbfs in Debian before lenny, but I think I would like to
see these final three points addressed before completely dropping
smbmount/smbmnt in favor of mount.cifs.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
