Re: variant symlinks vs VFS, and microkernels vs error kernels

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Fri, 3 Oct 2003 15:11:10 -0600
Mike Porter <mupi@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
overwhelming.

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.:

http://www.geocrawler.com/mail/thread.php3?subject=symlink+question&list=159

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.

-Chris