At Thu, 25 May 2006 11:30:54 +0200, "Michal Suchanek" <[EMAIL PROTECTED]> wrote: > > On 5/24/06, Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > At Wed, 24 May 2006 16:37:47 +0200, > > "Michal Suchanek" <[EMAIL PROTECTED]> wrote: > > > > We already have a mechanism to provide such capabilities. It is > > > > called a "file" capability to the binary image. This is all I need to > > > > support all the features I want to support. Everything beyond that is > > > > "in the way". > > > > > > If you give up the possibility to create restricted binaries the > > > binary will not exist in the first place. It will be part of some > > > service, and you will never see that there is a capability. And you > > > will not be able to trace it anyway. > > > > Somehow the discussion managed to drift away from its starting point. > > My response to Jonathan was about using the constructor mechanism as > > the prime mechanism for program instantiation, that means all cases, > > in particular those which are not the controversial, restricted ones. > > It is those cases of program instantiation I was talking about. > > > > But in the case the binary is not restricted in any way you can give > it the capabilities you want and trace it to your liking. I do not see > how the constructor gets in your way in this case.
The constructor will, by default, give the program capabilities to some system services, like the meta-constructor and space bank, so that the instantiated program can authenticate capabilities to them. This mechanism has to be disabled, which requires an extension to the constructor, or you have to use the disclose functionality of the constructor to extract the program data and then use that to instantiate the program yourself, by creating a new constructor or by doing it manually. I did not say that it is impossible to do this. This is not how I used the words "in the way". However, it is not the direct way of doing it. In implementing my system structure, the constructor serves no purpose. It holds all the capabilities needed for program instantiation. Well, in my proposal, there already is such a capability, namely the file system (that contains the binary and all libraries etc). One can also see otherwise that the constructor is an extra step in the way towards the direct program instantiation that I want to achieve. Whoever creates the constructor has the right to destroy it (at least initially), and may destroy it at any time. This is ok as long as the constructor creator is the same agent as the provider of the binary image. But that means that you could have just as well gotten the binary image instead of the constructor from the same source. If there is a mechanism in place that you have to disable or otherwise work around to get what you want, then that mechanism is "in the way". If this mechanism serves no other valid purpose (a matter of judgement), it is not only in the way but also unnecessary. No system designer will include unnecessary mechanisms that stand in the way of doing things. Imagine the "open" system call would return the FD in a string, and not in an integer, and you would have to parse the string to get the FD back. Wouldn't you agree that the "string return value" mechanism stands in the way of getting the FD? The problem that you and Pierre have here, which is very clear from the arguments you are making, is not that you don't see how the constructor is in the way (both of you described very clearly how it is, actually, in the way), but that you firmly believe that the constructor mechanism is necessary, and not superfluous. This is, presumably, because you differ on the goals and objectives. But this is a discussion we had extensively, and it is not what this thread was about. Jonathan asked me what my opinion is in using the constructor to implement the system structure I proposed. So, if you want to comment constructively, you should look at it from the perspective of my model, and the goals it tries to achieve. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
