On Tue, May 23, 2006 at 11:43:10AM -0400, Jonathan S. Shapiro wrote: > > Protection for programs which are about to get capabilities which must not > > be disclosed to the wrong parties is fine. That is not what this is > > about. This is about protection from the user who owns everything that's > > known to the program. That must not be possible. The user must be in > > complete control in such a case. > > > > In particular, that means that when starting a sub-Hurd on a transparent > > space bank, it must not be possible that > > - A part of the sub-Hurd becomes opaque > > - A part of the sub-Hurd can see that it is running on a transparent (to the > > parent Hurd) space bank. > > Okay. Just so we are clear,
Thank you. I appreciate the effort to avoid misunderstandings. > there are two possible views about opacity, and you are choosing one. I haven't made a choice yet, actually. And I think your distinction doesn't quite capture the choice I was making. I'll try to explain. > The two possible positions are: > > 1. The default should be translucent, but it should be possible for > a user to choose to execute an opaque program. > > 2. The designers should not allow the user the freedom of this choice > in the absence of extensive new development effort, and therefore > mandate that all banks be translucent. You are (perhaps intenionally) forgetting the option that the default is opaque. I have indeed chosen to reject that. However, note that I have only chosen to reject opaqueness to the user. I do not have theoretical objections to default opaqueness for the parent process. As I said before, for me the process doesn't have rights. The child process doesn't have the right to demand opaqueness, but the parent process also doesn't have the right to demand transparency. The user does have this right, IMO. Of course if there's an other user (or "the system") involved, such as with ping, then that other user can also demand opaqueness. Things get complex if the demands don't match. :-) > It appears to me that you are choosing position (2). No, actually if I have to choose from those two, I think I'm tempted to choose 1. What I said is that I would like to choose 2 if that would not raise any problems. I now think that the ping case may actually show a real problem for which users will want to provide read-only memory. The competition case needs full opaqueness. I'm still open to both, in fact. But transparent storage is the default for me, and anything else will need justification. The point I was trying to make is that the system should not allow programs to make things harder that are possible anyway. That means that the machine owner must simply be able to see everything in the system if she desires this, and a program must not be able to hamper debugging it if all users which provide capabilities to it agree that debugging is a good idea. In the usual case, all capabilities are supplied by one user. If that user wants to debug the program, there should be noone who can make it harder, and in particular not the program itself. If this would be allowed, then what really happens is that programs are given rights to "want" things. Since programs don't have a will, this effectively means that programmers can let their programs execute their will. To some extend this will of course happen anyway, but I think the system should not provide additional support for this. Once a program is on my computer, I should be considered the owner of that program (from the system's point of view, juridically things are different of course). That means that the system should not allow the program to do things that I don't want. Forcing me to a choice between hacking the program and running it on an opaque space bank is certainly something I don't want. Things are much more complicated when more than one party provides capabilities. However, in the end everything is owned by the machine owner, and so for her no limits should be imposed by the system (which doesn't mean the machine owner doesn't limit herself, but that's a personal choice). Note that in the case of a sub-Hurd, the "machine owner" of this sub-Hurd is the user starting it. That's why no process within the sub-Hurd should be able to get protection against that user. > Speaking on a purely subjective basis, I find this incredibly arrogant, > and I think that the users will too. I will not deny that I am indeed incredibly arrogant, at least in some cases. This is one of them. I think we (I'm arrogant in plural, cool huh? ;-) ) know much more about operating systems than the user, and so it's up to us to make choices for which knowledge about them is needed. That includes imposing policy. Open-source people will probably say "hey, we're just engineers, it's not our responsibility what the thing is used for". I strongly disagree. The users simply don't know enough about it. There are choices which influence their lives, and they aren't educated enough (in this field) to decide what is right. We are, and I think it is our duty to make those choices in a way that is in their best interest. Not doing anything and letting them figure it out is a choice, too, and IMO it's a morally objectionable one. So yes, I am arrogant, and if the users read this they will likely agree. I'm not sure if they have a problem with it, though. ;-) 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
