smbmnt must be installed suid root...

[Mark Knecht]

On Thu, 03 Feb 2005 17:08:23 -0800, Rick Stevens
<rstevens at vitalstream.com> wrote:
> Mark Knecht wrote:
> > Hi,
> >    I am able to setup an NFS mount in fstab so that a user can mount
> > it but I cannot do the same for an smbfs mount. So far I always get a
> > message back saying:
> >
> > smbmnt must be installed suid root
> > for direct user mounts (500,500)
> > smbmnt failed: 1
> >
> > I did some Googling and see this is a fairly common post, but it seems
> > that the agreed upon solution is not. Some say that changing
> > permissions on smbmnt is a bad thing to do as it raises security
> > issues. What security issues?
> 
> Any command that's set suid root can be dangerous, as anyone can execute
> the command AND the command, when run, has root permissions.  That
> wouldn't necessarily be that dangerous as smbmnt is transient (it's
> invoked, does the mount, then goes away) so the window of vulnerability
> is relatively small.
> 
> >                               Do they apply to a home network desktop
> > system to any great extent. Is there some other way to do this that
> > will accomplish what I want?
> 
> Not really.
> 
> >    Here's the line from fstab: (Line break by hand)
> >
> > //GIGASTUDIO/16-Bit-loop /mnt/GSt-Gigs          smbfs
> >    username=mark,password=removed,noauto,user,ro 0 0
> >
> >    What's a good way to accomplish without messing with system security?
> 
> There really isn't.  Mounting non-removable media as non-root users
> really isn't supported for any filesystem type because of security
> issues and because there's no direct mapping of Unix security to Windows
> security models.
> 
> If you must, here's the rules:  If you set the "suid" bit, the program
> runs as the OWNER of the file.  So, first make sure the program is owned
> by root.  Then you can set the "suid" bit by (as root):
> 
>         # chmod u+s /usr/bin/smbmnt
> 
> When you "ls -l /usr/sbin/smbmnt", if you see an "s" for the user part,
> then it took.  An "S" (capital S) means the suid root bit stuck, but
> the program didn't originally have the execute bit set:
> 
>         s = suid AND execute set
>         S = suid and execute NOT set
> 
> If you wish to remove the suid bit, use "chmod u-s /usr/bin/smbmnt".

Thanks Rick. I guess the danger here is that some mistake could get
made at the command line, mount a Windows share and then compromise
that machine by accident. I think I want to be careful about that as I
have a lot of audio data on the Windows boxes. The fstab idea was an
attempt to limit what could be mounted.

Really I guess it doesn't need to be made so automatic as fstab is
capable of doing. To a great extent the reasons I wanted to put it
there were:

1) It mimics the mounts I do between the ogg file server (which is
Linux based) and my Linux desktop machine. If both are done in fstab
then there's one less place for me to look when I need to change
things.

2) I forget a lot of this stuff from week to week. I've not found any
good way to remember command line commands other than recalling stuff
from a history file which isn't deep enough to cover my bad memory. I
write stuff down and the papers or books get misplaced/lost. fstab is
more stable as long as the system is running and backups are current.

Cheers,
Mark