Date: Fri, 13 Jan 2006 20:14:49 -0800 From: David Leimbach <leimy2k@gmail.com> To: bu7cher@yandex.ru Cc: freebsd-current@freebsd.org Subject: Re: DragonFly Variant Symlinks port Message-ID: <3e1162e60601132014t20916189u28530c6fd674c77@mail.gmail.com> In-Reply-To: <43C84D42.000001.11272@mfront7.yandex.ru> References: <43C84D42.000001.11272@mfront7.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/13/06, bu7cher <bu7cher@yandex.ru> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3e1162e60601132014t20916189u28530c6fd674c77>