variant symlinks vs VFS, and microkernels vs error kernels

Chris Pressey cpressey at
Fri Oct 3 18:19:28 PDT 2003

On Fri, 3 Oct 2003 15:11:10 -0600
Mike Porter <mupi at xxxxxxxxx> wrote:

> I don't think we are talking either/or here.  There is no reason we
> can't do BOTH varant symlinks and VFS.  True, there is SOME overlap of
> features (VFS can do, probably, almost anything that variant symlinks
> can do) but! there are other considerations such as how much work is
> it to set up?  Are we going to force everyone to use VFS layers,
> "primarily for package management" (for *most* people).

No, we don't need to force anyone...
If VFS is done right, everyone will *want* to use it :)

> For me, for exmaple, VFS is waaay overkill; all I want is to 
> be able to install perl 5.8 and gcc 3.4, without killing my system
> compiler and perl interpreter.

Then, honestly, variant symlinks are probably overkill too.

I mean, in a sense, this problem was originally "solved" with $PATH - if
program X needs a specific version of Y, prepend the directory that that
version of Y is in to the $PATH, before running X.  Problem solved!...
except for li'l things like include files (generally have their own
$xxx_INCLUDE_PATH) and hash-bang (and I have no idea why hash-bang
doesn't honour $PATH) and fully-qualified references to programs for
security reasons and oh, by the way, $PATH generally just kind of sucks.

> Some of the other advantages that come along for the 
> ride, such as /usr/src as a varant symlink, allow me to more easily
> deal with multiple source trees are nice, but not necessary, in the
> same sense.

And even more stuff has the potential to come along "for free" with VFS,
as I understand it.

> [...] But why can't we have both?

No reason, except that multiplicity begets complexity.

Let me qualify that.  Insofar as the level of complexity is manageable,
diversity is a good thing.  After a point, though, it becomes

Yes, the level of complexity of using just varsyms and VFS together is
probably manageable.  But add to those: regular symlinks, hardlinks,
$PATH, chroot's/jails, unionfs/nullfs, paths and other magic *in*
varsyms, shell aliases, wrapper scripts, and executables that act
differently depending on the value of argv[0]... and you've got yourself
quite the rat's nest.

If I could scrap it all and just use VFS, I would.
At the very least, it would put all the configuration in one place, I
imagine, instead of having it sprawl everywhere, as it does today.

> [...] sure poking
> through /usr/local/gcc/ would eventually get them a gcc, but changing
> permissions on the directory /usr/local/gcc/ to prevent execution
> prevents ls from showing anything, effectively blocking them unless
> they know enough to guess the directories below it.

I realize it's a subtle and somewhat paranoid idea that's probably more
appropriate in OpenBSD circles, but say I want to really lock down a
system in this way.  I don't just want a directory that can't be listed
- the very existence of such a directory could give an attacker clues
about how I've set up my system.  And let's say there's a badly-written
setuid binary lying around; the attacker might be able to exploit it to
get into that directory.

But if the directory is effectively *not there*... if the attacker can't
even stat it, not even an exploitable setuid binary will help him/her
get inside.

And if the real underlying filesystem is only available in single-user
mode, maybe even the damage that could be done should that attacker gain
root access, could be mitigated.  I kind of doubt it, but who knows? 
The thing is, VFS is a step towards this, even if it doesn't get there;
whereas varsyms are a step to the side, albeit one that would come in
handy for lots of things.

> > Where's the fire, though?
> OK, but why is it such a Bad Idea?

It's not, if you can handle it.

But for the sake of making the case against it, it's yet another
econo stud in a wall that should be burnt down and re-built out of
bricks :)

> yes, except that fBSD for whatever reason, has apparently refused to
> adopt it.

It's a contentious issue; from what I gathered googling, a lot of it is
people who used and loved Domain/OS versus people who are convinced that
anything as context-sensitive as variant symlinks must be The Devil.

Although sometimes there are some valid points made in between the
strong feelings, e.g.:

Anyway, contentious ideas tend to get skipped over in favour of less
contentious ones in most big projects, so it's not that surprising.

Also - I'm trying to avoid making a case against them on that level. 
Good or bad, variant symlinks would be just plain *unnecessary* in the
presence of a well-done VFS.  At best, to me, they're scaffolding to
help get us to that point, and as such, we needn't be perfectionists
about them.


More information about the Kernel mailing list