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

[Mike Porter <mupi@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 03 October 2003 07:21 pm, Chris Pressey wrote:
> On Fri, 3 Oct 2003 15:11:10 -0600
>
> No, we don't need to force anyone...
> If VFS is done right, everyone will *want* to use it :)
>
As sander pointed out, what about sysdmin overhead?  Yes, VFS is desireable, 
nobody here (that I know of) is arguing anything else.  However, for my use, 
which is basically my computer at home, I don't need VFS.  I don't want to 
spend the time configuring it, and making it work right.  I would probably 
play with it some, so that I would know how at some point in the future when 
I may need it, but unless it has something other than things previously 
discussed, it simply isn't worth it for my situation.

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

AS you point out, $PATH doesn't actually solve the problem.  Installing, e.g., 
a new version of gcc will almost certainly mangle something in my system's 
compiler.  Done right, under variant symlinks, the new version of the 
software will never see the stuff which belongs to the old version of the 
software.  Yes, it is less 'secure' but security is not the primary concern 
for me.  As I said, I have my one computer; its not like I am hosting the 
hotmail site or something, where there are 20 million people trying to break 
my site every day.

> > 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.
>
yes but at what cost does the stuff come 'for free'?  with variant symlinks, 
there is no cost if you don't define them.  With VFS, I assume you could turn 
it off with kernel options, and there would likewise be no cost....but also 
no benefit.  variant symlinks could also be set up to be disabled from kernel 
config, as well as on a per-filesystem basis at the time mount is run by 
specifying a flag.

> > [...] 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.
>
none of these would be really any different with or without variant symlinks, 
especially if we do as matt suggests, and simply treat them as symlinks for 
the purposes of ls and the like.  This does make a stronger case for VFS for 
those who are wanting something to enhance the security of their system. 
(something that nobody has claimed, at least not that I saw, for variant 
symlinks).  argv[0] is not going to go away, regardless of whether you use 
VFS or variant symlinks.  but the variant symlinks make it clearer, where VFS 
can make it appear that it acctually is a different program.  hardlinks and 
$PATH will still be present in VFS.  chroot/jail will be much nicer, 
stronger, anyway, with VFS; but nothing in variant symlinks changes this or 
makes it harder or more complex.

> 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.
>
If you are seriously in need of a system that secure, just run "ifconfig 
<interface> down" and you needn't worry about 'net attacks from <interface>.  
There's still physical security to worry about, but if you can't control the 
physical security of the computer, and the physical filesystem is accessible 
from single user mode anyway, it's a moot point; anyone who can comprimise 
your physical security will be able to defeat the VFS.

>
> 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.
>
My point is that varsyms are more than just "handy for lots of things" they 
actually solve real problems (like how to have a ports system that uses one 
compiler, while the system is restricted to a different version, without 
trampling each other's files) in a simple and elegant way.  VFS is designed 
to, and does a good job, of solving other problems--certainly very real 
problems to those that have them, but different problems, nonetheless.

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

I think that remains to be seen.  In my experience, any such layer involves a 
great deal of setting things up, configuring, tweaking etc.  Even if the 
underlying code is sound, there is still a lot of individual configuration 
that needs to be done; take jail, just as an example, one of the things which 
VFS purports to 'solve.'  For the majority of users, I don't think that level 
of complexity is necessary.  I agree wholehartedly that for those users who 
*DO* want it (and I would suggest that it is a not-so-insignificant 
miniority) we should provide it.  I *don't* think that any core functionality 
of the OS should be based on it.  Remeber the problems with 'stacker' or 
'doublespace' or 'drivespace' or whatever they are calling it these days?  I 
believe that the ports/packaging system is part of the core functionality of 
an OS.


 mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/fufoY30jZzkECLcRAg5oAKDDqHpF5biJA22fRve7Gt0bPQeWgQCfXYOf
MlSluOkkzqhRPqdA9eHXg34=
=hkgn
-----END PGP SIGNATURE-----