DragonFly kernel List (threaded) for 2003-10
Re: variant symlinks vs VFS, and microkernels vs error kernels
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
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... 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
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
> 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