From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 03:13:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6321F3EC for ; Sun, 23 Feb 2014 03:13:14 +0000 (UTC) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34B2A1EE2 for ; Sun, 23 Feb 2014 03:13:14 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id rq2so5061325pbb.23 for ; Sat, 22 Feb 2014 19:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4c4VayxaK/Z50hm87ED9g1qclPuHvi1TUpejJYnWETE=; b=SOi2jJ5zLSAXk6CMgeGzJwpxzVUT7LaqesNvY+W49GLGszPYitdOmnBymO/rJUoRSu TkW8wUO9trzJTPlbMtDZ1bCK9gqHhdFj2+iwgvthu/oP6bhUz5yZY/mRsDIzN3G9TyeC QUO6K0rXxlyp7maHwU0eOhPF2+WSl1k3TgtBJ3ypCy7vinxuc1fNkmnZBUGm3em35w97 MZVBXDg8/pUPCAmAIzvVjJwqtr8Mo28yz8OWodsF8m8OnpHPoCREhGumLiwWDXij4kYr m5uGrK6w2ht0o7TaKQp9zDaZYn4D2ca6NWwumz+EQTti0IAe6ajt0OaqOr9ufWGDd+Dj ta0A== X-Received: by 10.66.141.197 with SMTP id rq5mr3769134pab.64.1393125193877; Sat, 22 Feb 2014 19:13:13 -0800 (PST) Received: from [10.20.30.117] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id tu3sm85830706pab.1.2014.02.22.19.13.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Feb 2014 19:13:13 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Jordan Hubbard In-Reply-To: <53092D83.6050603@digiware.nl> Date: Sat, 22 Feb 2014 19:13:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 03:13:14 -0000 [ 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 = 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