Date: Sat, 22 Feb 2014 19:13:09 -0800 From: Jordan Hubbard <jordan.hubbard@gmail.com> To: Willem Jan Withagen <wjw@digiware.nl> Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Perry Hutchison <perryh@pluto.rain.com> Subject: Re: Thoughts on Multi-Symlink Concept Message-ID: <E4045817-9A79-42CD-B69F-7D3C8A2D861B@gmail.com> In-Reply-To: <53092D83.6050603@digiware.nl> References: <CAO2cuEMC==HstC4VkkiFpHyo6LA_xyCjYKvCEECXneVLNnZpZg@mail.gmail.com> <A31B3F88-861F-459B-AD67-F146D5514594@mail.turbofuzz.com> <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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@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=92s = 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=92s = =93universe=94 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=92t 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=85 Which is interposing at the libc level=85 I=92ve seen a number of = surprisingly successful =93science experiments=94 with filesystem = interposing at the libc boundary, trapping all the filesystem access = functions in order to, for example, figure out during a software = package=92s 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=92t = completely relegated to various =93rescue=94 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=92t have access to the target of = a symlink without variable expansion, I don=92t 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=92s even easier. Either way, I think it=92s fair to say that one can shoot down almost = any good or interesting idea with =93but 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=92s just hubris coupled with a longing for = the =93good old days=94 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=92s a security = guard with a gun at their bank. The guard can=92t do much if a customer = walks in and withdraws their own money to give to the con man who=92s = 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=92s time for = some of those ideas to enjoy a renaissance? Sounds like a good = EuroBSDCon or BSDCan talk. :-) - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E4045817-9A79-42CD-B69F-7D3C8A2D861B>