Date: Wed, 23 Jun 2004 02:21:21 +0200 From: Simon Barner <barner@in.tum.de> To: Doug White <dwhite@gumbysoft.com> Cc: AK <lesha@intercaf.ru> Subject: Re: vfs.usermount not working anymore on SMB shares? Message-ID: <20040623002120.GA31046@zi025.glhnet.mhn.de> In-Reply-To: <20040622153317.W79584@carver.gumbysoft.com> References: <200406210450.39636.lesha@intercaf.ru> <20040622153317.W79584@carver.gumbysoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug White wrote: > On Mon, 21 Jun 2004, AK wrote: >=20 > > $ mount_smbfs //LESHA@ROUTER/USB /home/lesha/samba > > mount_smbfs: can not setup kernel iconv table (default:tolower): syserr= =3D > > Operation not permitted > > $ sysctl vfs.usermount > > vfs.usermount: 1 >=20 > 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=3D1? =20 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 --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA2M0ACkn+/eutqCoRAnTKAJ9VceDaZ8SmQJu3pdQSVisFHhg2/QCfdTNu 9BWOZBrmP3/NT5RbzU3711k= =m85r -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040623002120.GA31046>