On Tue, May 16, 2006 at 10:16:47AM -0400, Jonathan S. Shapiro wrote: > What Bas is saying is complete bullshit.
Thanks. :-) You may want to relax a bit. ;-) > EROS doesn't do this "because it is EROS". I didn't say that. I said I was assuming this was how the constructor would be implemented in the Hurd if it would be implemented, because this is how EROS did it, and I had no further information about changes to the design (as it would be implemented in the Hurd). I had no idea why EROS did it like this, and so I didn't make any statements about that. > EROS does this because 40 years of experience says that the default has to > be opaque or security fails. That sounds reasonable. It also sounds incorrect. :-) > 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. Ok, this is a technical thing. I'm assuming that the space bank can provide me a page of memory which I can use. If it's hard, I'll use a library for it. No problem. > 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. You are assuming that there is a constructor, and you add something to it to make it "simpler". I am removing the constructor (moving part of its functionality, creating a new process, into a library) and claim that that really makes things simpler. It removes a step of indirection. Instead of asking a server (the constructor) to create a process, I can just do it myself. > 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. Nonsense. If a process requires opaqueness, there must be a way to allocate opaque storage. There's no reason at all that it must be the default. > 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. Actually, I think in most cases we very much do want this. Maybe even in all cases (but we're still discussing that). > 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, If you see it coming already, then it should be easy for you to find an actual use-case where this problem shows up. Please share this with us. > 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). They shouldn't rely on user-supplied storage for things that they don't want to share with the user. They can rely on user-supplied storage for all other things, which is a lot. Actually, the non-sharable part would usually be constant size, I think, so in that case there is no problem. > The problem with this is that there is a "free rider" problem that leads > directly to denial of resource. It would if the size is not O(0). Please give an example of a case where it isn't. > 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. Does it? The only new part is that --x permission cannot be given. That is, x implies r (and r implies x). I don't think I've ever seen a situation where users were not given read-permission to a binary that they could execute, that was actually useful. The only reason I know for its use is to make it harder for crackers to find bugs in it. That is security through obscurity. It doesn't work. > 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. That's not what Marcus' proposal says either. The only "new" thing (compared to EROS) is that it says "if you want me to run your code, you need to give it to me". That has been the case forever when going outside the single-computer situation. It has been normal forever (as far as I know) within the single-computer situation as well. I understand that you consider EROS "normal", because you've lived with it a lot longer than we have. But for us, "I want to run your code, but you don't need to give it to me" is something new. And we don't see the usefulness of it as automatically as you do. > 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. Privacy is about what I do with my things. Not about what you do with my things. Transparent storage doesn't invade my privacy, it only doesn't allow you to let me execute a program on my own resources without seeing it. > 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. Not at all. The storage is transparent to the user himself, not to the rest of the world. It is based on the assumption that only users have rights, and programs don't. So a user can choose to have his storage not inspected by anyone (because he'd have to give it away for that to happen), but a program cannot (because the user can look at it without permission from the program). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
