variant symlinks vs VFS, and microkernels vs error kernels
mupi at mknet.org
Sat Oct 4 08:36:52 PDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
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 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the Kernel