On Fri, 2007-01-12 at 19:17 +0100, Marcus Brinkmann wrote: > Hi Jonathan, > > is this intentionally off-list?
No. The problem is that l4-hurd is the ONLY list I am on that fails to set reply-to, so it is easy for things to go off-list by accident. This is the wrong default behavior, but mailing list theologians do not care. > > At Fri, 12 Jan 2007 11:02:23 -0500, > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-01-12 at 16:18 +0100, Marcus Brinkmann wrote: > > > At Thu, 11 Jan 2007 20:36:08 -0500, > > > > The problem is that the ProcessCreator was built with my storage. This > > > > means that I can inspect it, which means that I can extract the secret > > > > brand capability. The ability to extract the brand capability means that > > > > I can violate the integrity of the process type system. If this > > > > integrity is violated, the foundational chain of trust is broken because > > > > even the *primordial* servers cannot be reliably identified. > > > > > > This is correct, but only if the primordial servers are instantiated > > > by subordinate or lateral programs. In a system with translucent > > > storage this is obviously a very bad idea and a violation of a design > > > constraint. As I said before, in such a system the resource hierarchy > > > must coincede with the trust hierarchy, which enforces a strong design > > > discipline in this regard. > > > > I think you misunderstand. There is no reason why an arbitrary party > > should not fabricate a process creator and/or a constructor. > > Sure. In the current Hurd system there is no reason why an arbitrary > party should not fabricate an auth server as well. But it would be a > mistake for lateral or dominating programs to rely on that service in > any way. > > So, maybe in EROS there is some useful (to some) design pattern where > arbitrary parties can fabricate process creators and constructors, and > provide them to lateral parties, and everything still works as > expected. I am not sure I really understand this scenario, but I > assume it exists. Then this scenario is not supported in a > translucent system, because of what I said above. > > I think the relevant distinction here to make is the scope to which > the service provided by the process creator and constructor is usable > to others: In the EROS system, it seems to be laterally usable, while > in a translucent system it is only usable by subordinated programs. > > But it may well be that I am missing something still in your example. Things are still coming to my mind in the middle of the night, but so far I think this is a very good summary. > > In a translucent system, your solution works mainly because the "real" > > programs will all come in through the installer, and *that* storage is > > only inspectable to God and root (which returns us to an earlier email). > > It's a bit more general than that, but approximately yes. -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
