Hi, To load a mobile object we first need to load its code base that has been specified by the sender of the object. The ideal way to do this would be to send a port to a .so file and then load that.
If we loaded the code module unconditionally, the sender could essentially inject arbitrary code in the receiver. So we need to determine who has control of the module and only load it if it is a trusted user, e.g. the same user or the root user. But the FS interface does not provide any means to do this that isn't easily faked. Checking who the owner of the file is just gives you a UID which is just a plain integer. And there doesn't seem to be anyway to check who controls the actual translator either. It hit me that what we want is essentially reverse authentication. That is, letting the sender authenticate against the receiver, which would normally be the server and the client respectively. After this the receiver will know for sure who controls the module. Of course implementing this operation in existing translators would be a chore. And I don't know if it will ever be useful for anything else, though the concept is generic enough. Instead we can provide a translator that provides this reverse authentication but otherwise proxies its underlying node, or perhaps just gives out a unproxied port to it directly. This is has some other advantages. It would be possible to ``bless'' code modules as appropriate for loading on a case-by-case basis. Instead of loading any old file that happens to be owned by a trusted user. For a normal user to provide its own module, it would now be a simply a matter of blessing the module and then pointing the mobile object provider at it. For instance, settrans libfoo.so /hurd/bless-code. Another interesting possibility would be to let the code modules be translators themselves. It would be kind of nice keeping it all the needed functionality in a single file. Though I'm not sure how it would be implemented. On the flip side it would mean that code would be shared through a trivfs-like library, instead of in a separate program which is usually prettier. 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. This is a reasonable requirement for optimization, for which the extra assurance that the code is exactly the same increases reliability. But I'm not so sure about ioctls... Regards, Fredrik