On Tue, 2006-05-16 at 01:12 +0200, Pierre THIERRY wrote: > Scribit Bas Wijnen dies 16/05/2006 hora 00:47: > > What I want to avoid is this: > > - User starts program P > > - Program P calls server S, which needs storage > > - P provides some of its storage, and makes it opaque > > - User cannot inspect and/or change his own storage, because P > > opaquified it. > > > > If this is a standard operation of a space bank (that is, one that you > > get access to when you create a new sub-space bank), then this is > > possible. > > Whatever standard operation a sub-space bank provides, it changes > nothing about the upper space bank. If user has read/write access to it, > it won't change. If anything asks for opacity in a space bank, then > recursively each space bank in the hierarchy must accept to give away > inspect capabilities to the specified resource. > > At least this was the only sensible way to operate, as I see it. > > > > > If the default is to use opaque storage, then that dialog would be > > > > very annoying (popping up at every single process instantiation) > > > Why the hell should it be the default?! > > Because it is in EROS, AFAIUI. As far as changes aren't specified I'm > > assuming the EROS implementation (as far as I know about it). > > I found very few information about constructor implementation in EROS, > where did you find that opaque storage was the default for every process > instanciation?
What Bas is saying is complete bullshit. EROS doesn't do this "because it is EROS". EROS does this because 40 years of experience says that the default has to be opaque or security fails. Pragmatics first: Making the space bank transparent won't really help. The space bank does allocate address spaces. It allocates pages and nodes. In order to get useful information out of that, you would need to know how the pages and nodes are arranged, which is very hard. If you really want to make constructors transparent, there is a MUCH easier solution: add a new "create" call to the constructor that returns a process capability to the requestor (the process capability names the new yield). This gives the requestor all of the same authority that the process itself has. Rationale: Opaqueness is like virginity. Once you give it up, you can never get it back. In consequence, if *any* process *ever* requires opaqueness, the default must be to make storage opaque. This is fundamental. There really *are* programs that need to manage sensitive state, and you really *don't* want those programs (in most cases) to have to run off of system-supplied storage. The system design that Marcus proposes relies on a process hierarchy with trusted system processes close to the top. A problem with this design, which will become apparent to developers after 2-3 years of coding, is that this design only works in a transparent storage design IF those servers supply the storage for all of the operations that they perform (i.e. they never rely on user-supplied storage). The problem with this is that there is a "free rider" problem that leads directly to denial of resource. I want to be clear: the design that Marcus has proposed has eliminated more of these kinds of issues than I would have expected. It has not eliminated all of them. Policy: I am very very concerned about the extremist ideology of transparency here. This goes ORDERS OF MAGNITUDE beyond what is required by GPL or FSF. GPL does not say "if you run my program, you must disclose all of your data". It does not even say "if you modify my program, you must give away the modifications". It says: if you *redistribute* the modifications *then* you must disclose. It notably does NOT say that if you connect two programs that you run with an IPC pipe then you must disclose. GPL works extremely hard to strike a careful balance between privacy and disclosure. It is instructive to note that it protects *both* very strongly. Just as I cannot modify GPL to reduce your obligations of disclosure, I also cannot modify GPL to *increase* your obligation of exposure. Another way to say this is that I cannot modify GPL to *decrease* your right of privacy in the context of private use. I cannot narrow the conditions under which privacy holds. The "no encapsulation" or "transparent storage" policy is fundamentally a step that increases the users obligation to disclosure by reducing the conditions under which private execution can be accomplished. It is based on an assumption that the conditions under which privacy should hold should be narrowed greatly, and that users of GPL software should, by default, be required to publish their uses. I believe that this proposal fundamentally violates the privacy protections that are built into the GPL, and I question whether it is appropriate for an FSF-hosted project to do that. Jonathan _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
