Thoughts on Multi-Symlink Concept

[Jordan Hubbard]

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

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.

Either way, I think it’s fair to say that one can shoot down almost any good or interesting idea with “but but it could create a security hole!!" and I think that does the cause of evolution much disservice.   Some OS folks like to think that their corner of the universe is where the rubber really meets the road in terms of (protecting, providing, enforcing) security, but that’s just hubris coupled with a longing for the “good old days” when such fallacies of thought was closer to being true.   Now, of course, the bulk security attacks are centered around tricking users into doing things that compromise their own security, much like a good confidence trickster can con someone out of large sums of money regardless of the fact that there’s a security guard with a gun at their bank.  The guard can’t do much if a customer walks in and withdraws their own money to give to the con man who’s waiting outside the front entrance. :-)

But, ahem, I digress!!

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

- Jordan