variant symlinks vs VFS, and microkernels vs error kernels
sander at haldjas.folklore.ee
Fri Oct 3 18:52:40 PDT 2003
Chris Pressey <cpressey at xxxxxxxxxxxxxxx> wrote:
>> 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.
links and filesystem are different layers. Value of argv etc is again
totaly another matter.
>> [...] 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.
Fine. I can see a lot of uses for this. The question is merely one of
"are there significant enough areas where variant symlinks would be a
much better idea?". If yes, then a good argument can be made for having
>> > 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.
I have never used Domain/OS, or really never seen or used anything
Apollo related. I have done quite a lot of adminstration and release
> 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.
Ithink there are limits as to how simple you can make opertaions on vfs-s,
and variant symlinks would always be easier to use.
+++ Out of cheese error +++
More information about the Kernel