Hi, On Thu, Jun 11, 2009 at 07:07:35PM +0200, Carl Fredrik Hammar wrote: > 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.
I didn't think through what would happen when setting it as a passive translator, which is the probably the normal use-case. Then the translator will run as the owner of the underlying node. If the underlying translator isn't run as root or the same user then the start-up will fail. Which is as it should be, so this doesn't cause any problems. This differs slightly from what happens when it is set as a active translator. As in that case it will run the setting user, which might differ from the owner. Most likely the underlying translator will only allow the owner or root to set the active translator, but who knows. I don't think this inconsistency needs fixing, since it's pretty much the normal inconsistency between passive and active translators. Regards, Fredrik
