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

On Wed, Jun 23, 2004 at 02:21:21AM +0200, Simon Barner wrote:
> > 
> > Try loading the iconv kernel module first.  While usermount lets users
> > mount, it doesn't let them load kernel modules.

	This is very close to true, but to be more precise: kernel
iconv tables can not be loaded by plain user.
> 
> cd9660_iconv.ko, msdosfs_iconv.ko, udf_iconv.ko, ntfs_iconv.ko and
> libiconv.ko

	smbfs works with iconv interface directly.
> 
> - 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.

	Right, they're needed user mounts to work and this is less evil
choice in the terms of security, but still, not very perfect.  The reason
is simple: by abusing ability to load kernel tables user can intentionally
fill all of the kernel memory.
> 
> 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?

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

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

	The simplest solution is to preload all necessary conversion
tables via creating some mount points as root.  iconv interface will reuse
them for all subsequent user mounts.

	The more proper solution will be an userland utility which can 
preload tables at boot time.

-- 
Boris Popov
http://rbp.euro.ru