Hi, As I already said on IRC, I do see some merit in the idea of reverse authentication, i.e. file objects authenticating against clients. It makes sense to consider files as active objects, which have access to certain user IDs. (The fact that a file system usually provides a whole bunch of individual objects, is just an implementation detail.)
The funny thing is that while there is no standard interface to expose the authority information, file systems nodes can indirectly prove they have access to certain user IDs, by starting a translator on the node. This is what your code blesser makes use of. It is rather hackish though, creating some practical problems -- if we ever mean to use reverse authentication seriously, we better provide a proper interface in the filesystems themselfs. Anyways, while I see some merit in reverse authentication of files, I still don't think it is terribly useful for the migration framework. Having to explicitely bless every module is unrealistic; so in the standard case, we should just let the sender provide the authentication; and reserve explicit code blessing for the few cases where the sender can't, if at all. In almost all cases, the sender itself is trusted. As I have said before, I don't think it's terribly likely that users really want to access servers run by other, untrusted users. And the case that a user we don't trust runs a server which we want to access, but using modules we have blessed, *and* still really really needing migration, is even less likely -- I tend to consider it purely academical. Certainly not worth complicating the framework for it... Another case of YAGNI I'd say. -antrik-
