Hi, On Mon, Jun 29, 2009 at 11:23:34AM +0200, Carl Fredrik Hammar wrote: > > > The only real problem with specifying the module by port is that the > > > receiver needs to load the exact same module and not a copy of it. > > > > I don't consider that a problem :-) > > Consider Alice who wishes to use ioctls provided by Bob. Now, Alice > trusts Bob enough to use his servers, but not enough to load code provided > by him. > > After inspecting the source code of the ioctl handler, she trusts this > particular code provided by Bob. So she copies the source code and > compiles it to an identical copy of the module used by Bob's server. > However, she still can't use the server since it provides a reference > to Bob's copy, which he can modify at any time. > > Now I know you think that using other user's servers is a dubious > use-case. But code is just plain data, it should be enough to trust > a copy. > > I can't think of a way to support this use case if the module is specified > by port. It can only be done when specified by symbolic name, I think. > If we want to make sure the code is identical, the sender could provide > a SHA1 hash of the code it's using, or something. Such a check would > make it impossible to use a module compiled with different flags though... > > Anyway, I keep going back and forth between symbolic names and port > references. I'm not really convinced either way yet.
After writing and sending this, I realized that I should've resolved this conflict earlier. Somehow I had convinced myself that port references where the way to go without reasoning it through properly. To reiterate, the alternatives for specifying a code module are: Symbolic names: simply load the module with a given name where libraries are normally found. Port reference: send a port to the module file and load it. And I have already established that trust can be determined in both cases. So we need to look at other criteria to decide which to go with. The first one I have considered is the ability to load different but compatible versions of the module. For instance, so that one can load a module with debugging symbols when debugging. Or if the module used by the sender is from a source not trusted by the receiver, the receiver might locate a compatible version or copy it can trust. Using symbolic names handles this naturally, since the receiver's user can simply install the modules of his choosing where they will be found and override the system's modules. Port references can't handle it properly. In fact the only way would be to use symbolic names as a fall-back mechanism if the port reference can't be trusted. Though this is mostly a convenience issue. Because the module can be seen as a part of the server, it is reasonable to state that the server if the server can't provide a trusted module then it's a bug in the server (or its setup). The second criteria is whether the receiver can load the module if it uses a different root directory than the sender. This might sound like exotic functionality at first, but it isn't for the ioctl use-case. An application that chroots itself to an empty directory for security, and then tries use an ioctl on a file opened before the chroot would fail because it can't load the necessary ioctl handler module. Port references handles this case naturally, since it never uses the root directory. And the only way to make it work with symbolic names, is if the directories the modules are searched for are inherited from parent processes the same way the root directory is. Which would be a very invasive change to the Hurd. Given this it seems that port references is indeed the way to go. If we want to be able to load alternative versions, we can add a look-up with symbolic names later, using either it or port references as a fall-back. Regards, Fredrik
