Thoughts on Multi-Symlink Concept

[Willem Jan Withagen]

On 23-2-2014 4:13, Jordan Hubbard wrote:
> [ Whoops, my previous reply did not do this one justice - replying to
> the other parts of the message now! ]
> 
> On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen <wjw at digiware.nl>
> wrote:
> 
>> I was running a special patch version 2.2 at one time, that had
>> variant replacement in the lookup-cache routines. But I never was
>> able to figure out a handy way to get the info back into the
>> kernel.
> 
> IIRC, Domain/OS dealt with this by making the environment part of the
> kernel namespace - e.g. the userland access to it,
> getenv/setenv/**env, were actually fault requests back into the
> kernel for the information.  I believe there were even some
> limitations on setenv replacing existing entries because of that, but
> I may be mis-remembering another Unix’s recapitulation of the same
> feature.  Domain/OS was very influential in that respect, and I
> recall several others who tried the variant symlink idea, or riffed
> off the concept in a more limited fashion (Pyramid’s “universe”
> concept and conditional symbolic links comes to mind).

One was not able to replace all ENV variables in such a way that it made
it into the kernel for variant replacement. Things like NodeID etc...
were hardwired.
But I don't remember any serious limitations that hindered Unix type
behaviour. I probably still have some Domain/OS architecture whitepapers
describing hthis. But you are probably right in that it was actually
part of the users kernel-space.

[ I remember that the way Domain/OS translated its internal PID into the
Unix PID was much more cumbersome. The details have evaporated in
history, other than that I had to give Wietse Venema access to our boxes
to actually get him convinced that I did not smoke anything when doing
some tests for him.]

> I think to do it now, however, we could take an approach which you
> mention but I think don’t credit enough:
> 
>> So I gave up. One would need to get at the user environment of the
>> process, and then parse and scrutinize the ENV every time you need
>> to use a replacement. So probably libc is the place to put it, but
>> then you get into trouble again when somebody uses the not standard
>> libc…
> 
> Which is interposing at the libc level…  I’ve seen a number of
> surprisingly successful “science experiments” with filesystem
> interposing at the libc boundary, trapping all the filesystem access
> functions in order to, for example, figure out during a software
> package’s build process, just what header files it read, which helper
> binaries it executed, and essentially what its dependencies on other
> software packages were.  Same with variant symlinks, or per-process
> namespaces (where a given process tree sees a different view of the
> filesystem hierarchy than others).  I think there are so few static
> binaries on your average Unix box now, at least not that aren’t
> completely relegated to various “rescue” roles where such features
> are less than interesting anyway, that doing it at the libc level is
> an entirely reasonable approach for the 99% case.
> 
>> Also got a lot of flack from people suggesting it would create
>> security problems.... (I beg to differ)
> 
> I would also beg to differ.  If you don’t have access to the target
> of a symlink without variable expansion, I don’t see how access
> *with* variable expansion is going to make one damn bit of
> difference!   The security crowd was probably more concerned with the
> notions of deliberately overflowing the expansion buffer by creating
> environment variables that expanded hugely, or to things with weird
> special characters embedded in them, but both of those challenges are
> easy to overcome.  If you choose to do it in userland, it’s even
> easier.

Which was exactly my argument. But it could create obfuscation and
sorts. I put it more to "what we don't know, we don't like" attitude.
And like I said, the business I was running took off, the patches
succumbed to bit-rot.

I especially like the solution of putting it in kernel-space, which
allows for one-time careful scanning...
Perhaps even have a setenv/export -vl to push env-values into a special
VL-env-buffer? and have a syscall(VLbuffer, {set,get,del}, name, val)

With help I would be tempted to dig into this again...
Haven't done any serious programming for quite some time.

>> But I would really like the timewarp back to 1985.
> 
> Indeed.  I often tell interns who are looking for interesting project
> ideas to simply look back into our own past.  Almost all the really
> interesting and cool research activities where operating systems are
> concerned seems to have happened between the years of 1970-1990.
> Sprite, Plan 9, Mach (hey, file space name servers anyone?), Domain
> OS, all kinds of neat ideas that sadly died or were forgotten in the
> name of consolidation, performance and expedience.  Indeed, the
> performance of some of those concepts was actually rather woeful when
> 4MB of memory and 1MIP were all you one to work with.  Maybe now that
> we have more hardware horsepower than we almost know what to do with,
> it’s time for some of those ideas to enjoy a renaissance?   Sounds
> like a good EuroBSDCon or BSDCan talk. :-)

Well I do regular talks about the state of the internet. And I start by
showing people a picture of an acoustic 300/300 baud modem (1980). to
compare that to 500Mbit fiber consumer links that you can get here in
the Netherlands. Some hold for CPU speed, or memory space.

And then we look at the growth of capabilities of applications, and
wonder if we do see a 10^6 growth there too.
And I can't help the feeling that we should be able to do more with what
we got.

But then talking like this, makes me understand why my hairs have gone
grey. :)

--WjW