Re: vfs.usermount not working anymore on SMB shares?

Doug White wrote:
> On Mon, 21 Jun 2004, AK wrote:
> 
> > $ mount_smbfs //LESHA_at_ROUTER/USB /home/lesha/samba
> > mount_smbfs: can not setup kernel iconv table (default:tolower): syserr =
> > Operation not permitted
> > $ sysctl vfs.usermount
> > vfs.usermount: 1
> 
> Try loading the iconv kernel module first.  While usermount lets users
> mount, it doesn't let them load kernel modules.

Hi,

I just tried that myself, and I have a few questions/comments:

- which iconv kernel module do you mean? In FreeBSD 5.2.1, I have the
following iconv modules:

cd9660_iconv.ko, msdosfs_iconv.ko, udf_iconv.ko, ntfs_iconv.ko and
libiconv.ko

Well, the first four are unrelated to smbfs, and libiconv is built
statically into my kernel, but I am getting the same error as the OP.

- I had a look at the source, and it seems that on MacOSX, mount_smbfs
installed suid root, but drops the privileges immediately at startup.

Only for two operations (one of which is the iconv table manipulation),
mount_smbfs very briefly switches back to uid 0.

I guess the #ifdefs aren't there for no reason, but anyway: Would this
be an option for FreeBSD? I know that suid binaries are to be avoided
strictly, but wouldn't this improve FreeBSD's usability as a desktop?

Of course there are counter arguments:
- Isn't the hole suid root thing an ugly hack, and shouldn't those
  iconv tables behave nicely if vfs.usermount=1?
  
  Would that be possible at all, and why was it implemented the way it
  is in the first place, i.e is it a security risk to allow users to
  modify the kernel iconv tables?

- Why care at all, when there is sudo which even allows more fine-grained
  control?

Of course, argument #2 doesn't really count because the current situation
is less than satisfying.

Please tell me which path you'd suggest to take, and I'll be happy to see
what I can do (beware: a volunteer ;-)

Simon