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

[Sander Vesik <sander@xxxxxxxxxxxxxxxxxxx>]

Chris Pressey <cpressey@xxxxxxxxxxxxxxx> wrote:
> On 02 Oct 2003 03:35:41 GMT
> Sander Vesik <sander@xxxxxxxxxxxxxxxxxxx> wrote:
>> Chris Pressey <cpressey@xxxxxxxxxxxxxxx> wrote:
>> > On Wed, 1 Oct 2003 17:47:44 -0600
>> > Mike Porter <mupi@xxxxxxxxx> wrote:
>> > 
>> >> As I said before, I don't see the point/need to make a program
>> >> 'unavailable' to a user (in any sense except that typing, for
>> >example,> 'gcc --version' will result in a different value).
>> > 
>> > What if I have users that I don't want to run gcc at all?  Granted,
>> > today I would set up groups and make gcc group-executable only - but
>> > this VFS-viewfs way seems much more elegant, because they wouldn't
>> > even have to know gcc exists.
>> 
>> If a variant symlink uses an unset variuable then the lookup probably
>> fails.
> 
> Not really what I was talking about, though... they can still go digging
> around for what the symlink points to, and launch it with the full path
> when they find it.

Yes, of course. Why is this a problem? 

> 
> On Thu, 2 Oct 2003 02:29:19 -0600
> Mike Porter <mupi@xxxxxxxxx> wrote:
>> On Wednesday 01 October 2003 08:57 pm, Chris Pressey wrote:
>> > What if I have users that I don't want to run gcc at all?  Granted,
>> > today I would set up groups and make gcc group-executable only - but
>> > this VFS-viewfs way seems much more elegant, because they wouldn't
>> > even have to know gcc exists.
>> 
>> I wasn't considering this.  however, for those users, even under VFS,
>> all they have to do is 'install' the port (however we define install)
>> and they get it back.
> 
> But if they can't see 'install' either... :)

They need to have access to a shell binary. That is all they are going to
need. 

> 
>> It really isn't any different using symlinks, except...if you have 
>> already installed all the versions, you can use gids to prevent
>> execution of all installed versions.  VFS could (it seems) simply
>> create a local copy of gcc, in the user's home directory, if
>> necessary, bypassing any restrictions (OK, I guess if the user is
>> putting gcc in their home directory anyway, it is a moot point, they
>> would be able to do THAT regardless of vfs or symlinks.
> 
> Well - if they don't already have a C compiler, they can't build it from
> source.  I suppose they could find a gcc binary for DragonFlyBSD out on
> the net somewhere - but how about if I require binaries on my system to
> be cryptographically signed?

Ultimately, if you leave sed around they can use the fact that regular 
expressions are turing complete...

> 
> The point is that I see VFS as being very *different* from variant
> symlinks.  Variant symlinks are yet another aliasing mechanism, like
> regular symlinks or 'use.perl', while the VFS would genuinely abstract
> the underlying filesystem layout away from the tools that use it.
> 
> I tend to favour cleaner solutions, even if they're more work.  I also
> prefer abstractions that have real teeth (ironically, because I've been
> bitten more often by toothless ones...)  I think the solution can still
> be worked towards in a piecemeal way, I'm just skeptical about this
> particular piece of meal.

But I think you are thinking of a different problem than say I am and
thus arriving at a different solution. If you want to independnetly
control what gcc, perl, libpng and libfreetypoe are in use, you end up
building at least 16 different filesystems, and possibly even more. 
This is much better done with setting up variant symlinks. Installing
a new version of gcc has no additional overhead, really.

> 
> I'm quite willing to take the performance hit, too.  Matt has suggested
> that, with his namecache niftiness, it will be negligible anyway.
> 

What about sysadmin overhead?

>> > > To me, the idea of a program being unavailable
>> > > means that no matter what I do as the user, I will never see/know
>> > > that the program is installed.  This to me is overkill.
>> >
>> > It IS overkill, for package management.  But it's not just for
>> > package management, right?  Done correctly, it could unify a number
>> > of disparate mechanisms currently in place.  chroot, for one.
>> 
>> That's why ultimately doing both is a good idea.  VFS certainly has
>> its place, and will work well for a lot things.  variant symlinks will
>> do a lot of the same things (not all) and should be easier to put in,
>> heck, even I might be able to do it, if I can ever find time (although
>> with my skills, I would almost certainly break something first <(}: ).
>>  As matt said, it will address  maybe 85% of the cases for VFS, and be
>>  easier to put in, should cost less (in terms of performance), and
>>  otherwise just seems a good idea. 
> 
> Where's the fire, though?

A number of things you can presently only do in awkward ways become very
easy and there are natural solutions to problems that presently require
high maintenance and are not scalable.

Variant symlinks are extremely flexible - they don't let you do all the
things VFS lets you do, but what they do they do very well.

> 
> As Matt also wrote: "correct choice of features", not "just laying on
> hacks"!
> 
> Perhaps it's a little unjust to call variant symlinks a "hack"; to be
> more polite, I should say that they strike me as one of those
> "incremental improvements" that would be happily adopted by FreeBSD 5.x,
> *if* people could agree on it.  It's an "easy, low impact" change that
> would provide "immediate benefits" in a "pragmatic way" and doesn't
> "make the kernel *too* much bigger and more complicated..."
> 

Okay - how simple can the best case of duplicating the functionality of
variant symlinks (which is basicly one api call / one shell command)
be if done with vfs? I guess interesting cases would be:
	* retargeting - instead of gcc-3.0.4 give me gcc 3.2.2
	* adding a new target - the system now has gcc 3.3.1
	* making a particular environment a users default startup
	  environment
	* making a particular enviornment be the default for a group
	  of users
	* starting from th previous one, make an alteration for one user

you can come up with your own syntax, for variant symlinks and my syntax, it 
looks like:

	* setlink GCC_VER "gcc-3-2-2" / setlink("GCC_VER", "gcc-3-2-2");
	* no extra actions required
	* add corresponding setlink commands to .login
	* add corresponding options to the login class / system login file
	* add a setlink command to .login of that user

which mostly summarises why I want variant symlinks.

PLease note I am not arguing against having teh vfs capabilities, just for
variant symlinks.

[snip]

> -Chris

-- 
	Sander

+++ Out of cheese error +++