Re: DragonFly Variant Symlinks port

On 1/13/06, bu7cher <bu7cher_at_yandex.ru> wrote:
> Hi, All!
>
> I have make the port of DragonFly BSD Variant Symlinks. (http://www.freebsd.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 changed to pointers).
> ToDo:
> 1. src/sys/i386/i386/machdep.c - this initialization needed for each platforms?
> 2. I think that here needed some locking implementation.
> 3. Document new syscalls.
>
> Any comments?
> --
> WBR, Andrey V. Elsukov
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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