Marcus Brinkmann <[EMAIL PROTECTED]> writes: > The active translator problem seems serious to me. Without any > guarantee about the implementation of a service, you can not know what > it does. This means that you must be prepared for any malicious > behaviour, including: no response (stalling the client), infinite > virtual directory tree, confusing inode numbers and link counts, > rapidly changing filesystem structure (to trigger race conditions) etc > etc.
I'm not sure how to do this; I agree with these problems, and it may be a more fundamental problem in the Hurd. > This is why in FUSE, users don't see the user filesystems of other > users. I am afraid that given the seriousness of the problem, this is > the only sane option. Only with a broader semantic framework can you > re-enable sharing on a case by case basis. This is of course the exact wrong answer, for just the same reason that you didn't like the Hurd's absolute separation as the way to get chroot jails. The point is to have safe sharing, not isolation. The problem is that people are used to filesystem APIs being of a certain kind of trustability. > Mach doesn't know on whose behalf the server does the allocation. I had thought that the solution here was to have a "resource allocation" handle, and users would provide it to servers, who would then use it to get resources. There are problems here with respect to untrusted servers, of course! Thomas _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
