From owner-freebsd-current@FreeBSD.ORG Sat Jan 14 04:14:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 95C5D16A41F for ; Sat, 14 Jan 2006 04:14:51 +0000 (GMT) (envelope-from leimy2k@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id C987D43D46 for ; Sat, 14 Jan 2006 04:14:50 +0000 (GMT) (envelope-from leimy2k@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so775692nzo for ; Fri, 13 Jan 2006 20:14:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XMfxGk2OX031ykncRK1oDzxTQTadWy3roffry+cOkytuvG4QOCVkJRAXig/4YLZq/R5OSzXv2VWX8u/FDduivGRy1vLBLhiVOEWJRNLaLb9DnhNCFEDL7Ly/Jd+F5iZJeYZSq5oWNqHx1utL0mLv8QFBh/pzh8UHw1ZW5tPU02U= Received: by 10.36.101.3 with SMTP id y3mr3112706nzb; Fri, 13 Jan 2006 20:14:49 -0800 (PST) Received: by 10.36.46.3 with HTTP; Fri, 13 Jan 2006 20:14:49 -0800 (PST) Message-ID: <3e1162e60601132014t20916189u28530c6fd674c77@mail.gmail.com> Date: Fri, 13 Jan 2006 20:14:49 -0800 From: David Leimbach To: bu7cher@yandex.ru In-Reply-To: <43C84D42.000001.11272@mfront7.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43C84D42.000001.11272@mfront7.yandex.ru> Cc: freebsd-current@freebsd.org Subject: Re: DragonFly Variant Symlinks port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 14 Jan 2006 04:14:51 -0000 On 1/13/06, bu7cher wrote: > Hi, All! > > I have make the port of DragonFly BSD Variant Symlinks. (http://www.freeb= sd.org/projects/ideas/#p-magicsymlinks) > Pathes for CURRENT can be founded on http://butcher.heavennet.ru/patches/= kernel/varsym/. This is first version and i think that work in not complete= . > Port is not fully identical with dfbsd implementation. Syscall interface = has been changed (removed messages-related things and some parameters chang= ed to pointers). > ToDo: > 1. src/sys/i386/i386/machdep.c - this initialization needed for each plat= forms? > 2. I think that here needed some locking implementation. > 3. Document new syscalls. > > Any comments? > -- > WBR, Andrey V. Elsukov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I'm not sure I like variant symlinks but it's still pretty cool that you ported them. I just hope that they are always optional on FreeBSD and not on by default as I'm not sure I'll ever really want to have them on my system. I have a much higher level of interest in something like Plan 9's private namespaces which can potentially eliminate the need for any kind of symlink at all [when combined with the ability to "bind" and union directories] There are potential problems with both private namespaces and variant symlinks though, both could get you into trouble if you do something silly like make a symlink out of /etc/passwd or even more directly with a "bind" over /etc/passwd in private namespace land. Then someone's environment variable or namespace can be used to switch out passwd databases. These things are still being thought out in the linux kernel with it's private namespace implementation too. Unix/BSD VFS and it's authentication model doesn't seem well suited to private namespaces either. On Plan 9 you have a host owner instead of a root user which has similar powers, but it's only because that's the person the filesystem server basically runs as or grants access to do anything on. There's no "file" per se that controls who has an account. It's done in a configuration section of the filesystem that's not readily exposed in via the VFS as a file that can be edited. [though I think you could edit a file and commit it to this section if you wanted to, I always use the filesystem's special console device to make such changes]. And that's just part of the story. The authentication part is done elsewhere. It seems like to have a really morphable or less global VFS we'd have to do something similar to what the plan 9 folks have done in their filesystem to make it more secure. Still, like I said, very cool that you ported it :-). I'm sure it will be useful when used judiciously. I just worry about security implications and how much I really understand about my system when such things are added. Dave