From owner-freebsd-current@FreeBSD.ORG Fri Jun 25 09:46:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DCBF16A4CE for ; Fri, 25 Jun 2004 09:46:08 +0000 (GMT) Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4537543D45 for ; Fri, 25 Jun 2004 09:46:06 +0000 (GMT) (envelope-from bp@butya.kz) Received: from lion.butya.kz (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with SMTP id DD6525855 for ; Fri, 25 Jun 2004 16:45:07 +0700 (ALMST) Received: from relay.butya.kz (localhost [127.0.0.1]) by localhost.butya.kz (Postfix) with ESMTP id C937D584D for ; Fri, 25 Jun 2004 16:45:06 +0700 (ALMST) Received: by relay.butya.kz (Postfix, from userid 1000) id AEFA9583E; Fri, 25 Jun 2004 16:45:06 +0700 (ALMST) Resent-From: bp@vertex.kz Resent-Date: Fri, 25 Jun 2004 16:45:06 +0700 Resent-Message-ID: <20040625094506.GA3643@vertex.kz> Resent-To: freebsd-current@freebsd.org Date: Fri, 25 Jun 2004 13:24:58 +0700 From: Boris Popov To: Simon Barner Message-ID: <20040625062458.GA58310@vertex.kz> References: <200406210450.39636.lesha@intercaf.ru> <20040622153317.W79584@carver.gumbysoft.com> <20040623002120.GA31046@zi025.glhnet.mhn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20040623002120.GA31046@zi025.glhnet.mhn.de> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: AK Subject: Re: vfs.usermount not working anymore on SMB shares? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 09:46:08 -0000 On Wed, Jun 23, 2004 at 02:21:21AM +0200, Simon Barner wrote: > >=20 > > 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. >=20 > cd9660_iconv.ko, msdosfs_iconv.ko, udf_iconv.ko, ntfs_iconv.ko and > libiconv.ko smbfs works with iconv interface directly. >=20 > - 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. >=20 > 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. >=20 > 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? See above. >=20 > - Why care at all, when there is sudo which even allows more fine-grained > control? Indeed. >=20 > 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=20 preload tables at boot time. --=20 Boris Popov http://rbp.euro.ru