variant symlinks vs VFS, and microkernels vs error kernels

[Chris Pressey]

On 04 Oct 2003 01:52:40 GMT
Sander Vesik <sander at xxxxxxxxxxxxxxxxxxx> wrote:

> Chris Pressey <cpressey at xxxxxxxxxxxxxxx> wrote:
> > 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.
> 
> links and filesystem are different layers.

One layer too many, if you ask me :)

Sure, it's fun making something on one mount appear to be on a different
mount, but I don't think many people would say it's a recommended
practice.  In fact I've seen the occasional rant to the contrary.

Also, I never could quite figure out why people insisted on pointer
safety in their programming languages and referential integrity in their
databases while happily accepting symlinks that can point to the moon.

And if they can now point to ${MOON}... heh.

Of course, like argv[0], symlinks are probably too ingrained to get rid
of completely - but that alone doesn't mean I should regard them as a
good thing.  And if one were to try to get rid of them, then a new fork
*would* be the place to suggest it, right?

> Ithink there are limits as to how simple you can make opertaions on
> vfs-s, and variant symlinks would always be easier to use.

I'd be interested in hearing why you say this.

On Sat, 4 Oct 2003 09:31:45 -0600
Mike Porter <mupi at xxxxxxxxx> wrote:

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

Similarly, I'd be interested in why you think VFS maintenance would be
significantly more work than variant symlink maintenance.

It's not just a matter of "easy to create" - spaghetti code is easy to
create, too...

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

I don't understand - VFS also solves the problem of how to have a ports
system that uses one compiler while the system is restricted to a
different version without trampling each others files - that's the
*same* problem, not a different one.

Simple - yes, variant symlinks are simpler than VFS.  But more elegant?
That's a bit subjective.  Dangly things are not, in my mind, very
elegant, and I do think a VFS solution could better enforce that they
don't happen.

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

So (putting straw men about how no security system is 100% invulnerable
aside) this looks like the sticking point - presumably VFS will be more
of a maintenance headache than variant symlinks.

Why?

Honestly, I don't see why it has to be the case.  In some ways, VFS
should be *easier* to configure than a hodge-podge of symlinks, chroots,
and $PATH tweaks.

I'm assuming that it will be possible to write a program that will allow
you (at least as root) to tell a VFS mount to change.  That is, at
worst: tell it to wait until it's not busy, umount itself, change its
configuration, and remount.  If it can change its configuration while
remaining mounted, or if it can unmount+reconfig+remount as an atomic
operation, all the better.  Call such a program 'vfs_ctl'.

Now, you can re-implement chroot, ln, and the like, in terms of vfs_ctl.
For an administrator who has already developed UNIX habits, the impact
on their routine is very small.

But that's not all - for administrators who want to develop *better*
habits, all of this information (what users see what directories, what
programs see what directories, and so forth) is stored in a single file
(say, /etc/vfs.conf), or, at least, a small set of similar nearby files.

So when you go and edit vfs.conf, you get a system-wide overview which
should reveal, with some clarity, how things are set up *in toto* -
information you would otherwise only get by digging through the
filesystem to find every symbolic link and relevant command in every
script and collating them.

That's my vision of it, anyway.  I don't know if it coincides with
Matt's vision in any way, shape, or form.  I'm also not saying we
*should* do it - I'm just making the case for it because I think it
would be something *good* to do.

-Chris