At 20 Mar 2005 14:35:15 -0800, Thomas Bushnell BSG wrote: > Thread moved over to bug-hurd since it's about design and not Debian > GNU/Hurd per se. Alfred Szmidt had pointed out that a dpkg > installation translator (one where you copy a .deb into a directory to > install it into the system) cannot be easily written, because Debian > package installation scripts are sometimes interactive. > > I said that this was a deficiency in the design of the Hurd, and that > it would be good to fix it (ultimately) by creating user interaction > context widgets which can be passed to servers so that they can safely > and securely interact with the user when necessary.
I think that's jumping to conclusions. First, the question of installing packages and user interaction is probably one of the simpler questions to answer. User interaction at installation time is horrible from just any point of view - interface-wise, administration wise, etc. It's heavily over-used in Debian, most of the time for completely silly reasons. With packaging support in the filesystem, this becomes even more true. In fact, the issue is even broader: Not only does Debian have user interaction, but it also runs arbitrary scripts at package installation, upgrade and removal. Now that is also horrible: It is a big security concern, it doesn't allow cross-installation, and usually it is only used to either fix up deficiencies in the system (like, the fact that the info dir file must be generated statically), or to cover up bugs in the packaging. There is a lot more to say on this topic, but the above considerations should at least motivate a careful analysis. Ok, this leaves the generic question of how translators can interact with users. This _is_ an important feature to have. One of the better examples I have is a password-encrypted filesystems that must be unlocked by entering a passphrase (not everybody has a card reader with pin number entry terminal). For laptops, the password must be dropped at hibernation and the cache must be cleared; at wake-up, the password must be retrieved a-new. I am also talking about programs like ssh-agent. Well, there are two separate issues. One is between active and passive translators. The other is between translator owner and translator users. For active translators, the owner (ie the one starting the translator) can explicitely set the environment in some meaningful way, but for passive translators this doesn't work. Passive translators get their environment from the parent filesystem, and that's usually the environment that's a bit like one a system daemon can expect. However, this could be solved by allowing users to set up a server that provides environments to other servers at their startup (these servers started up could fetch their environment from that server and use this instead of the one provided by the parent filesystem). I use the word environment losely here. It includes file descriptors, environment variables etc. This is all relevant for interaction with the owner of a translator or translated file. For supporting interaction with other users, which just happen to have access to the translator in some way, there are tight security considerations that must be taken into account. Not much is possible here. The best I can think of is that like with io_reauthenticate calls the open ports to the server can be configured in some way. This needs to be initiated by the client (for example in response to an error message). All the actual work (interaction with the person in front of the computer) must happen on the client side, or in some other service that is subsequently used by the client (just like the client uses the service of the auth server to configure its port's uids/gids). For example in the case of the filesystem, for an actively started filesystem that is encrypted at the storage level, it may be good enough to have an ssh-agent running at the desktop of the owner of the translator. For a passively started filesystem, some support is necessary that makes the filesystem aware of the ssh-agent if it is running, or in some other way allow the owner to provide the filesystem with its key. This is also a common problem in Unix if you want to run ssh-aware programs out of your cron job (this is why I store my SSH_AGENT variable in a file in my home directory, and have a wrapper script that provides uucp with the right environment. In fact, the analogy with SSH_AGENT is pretty good here. It's totally different if the filesystem has encryption at the file level, and different users own different files. Now, that is an interesting problem to think about, but as the filesystem has no mutual trust with the users, it can not just go and ask those user's services, even if the user provides the filesystem with ports to those services. It's highly questionable if you want to trust the filesystem with your passphrase anyway. So, in this case this seems to suggest to me that you don't decrypt the file in the filesystem, but in the user, with the added benefit that such a solution will work with _any_ filesystem if it supports encryption or not. The problem is that this would prevent memory sharing. Well, ok, we are talking about security here, but if sharing is not a security concern for you, you can still get it, if you just use a special proxy filesystem that you run as your user and that transparently decrypts the underlying files for you. As you are then the owner of that transparent proxy, the problem reduces to the above problem for which I suggested a solution. There is much more to be said about this, and this is by no means meant as suggesting specific interfaces and implementations. Everywhere where I wrote "must" above you can read "it seems to me that there are strong reasons that [it] should [be done this way]". > You walk up to the workstation and start a complex memory intensive > ray-tracing program. It runs out of memory and swap space on the > workstation. A dialog pops up informing you of the situation and > giving several options: suspend the job until later, kill it, and so > forth. (Notice that Unix and the Hurd both simply kill the process or > the system here, because the discovery that swap is gone happens so > low down that all context has been lost.) This is a defect in the centralized virtual memory management, and will not be true anymore in the Hurd on L4 (at least not if we get it to work our way ;). Of course, those options could still be provided to you. But this can, in the Hurd on L4, be completely implemented by the user with user-provided services, without any system support in addition to what we already specified or have in mind specifying. A lot of what you wrote seems to be just one possible way of behaviour to me, and in many situations not the most desirable one. Ultimatively, this must be up to the administrator. > then you log out. (Note that Unix and the Hurd cannot carry on at all > in such a case; failure to satisfy a page-in fault results in utter > disaster, not clean behavior. Also, neither control carefully which > data is paged to which devices, because all interaction context is > gone when pageout decisions are being made, so if you have started > paging on this disk, you have probably started paging all kinds of > essential system services on it too.) See above. This is going to be fixed, at least within reasonable parameters, in the Hurd on L4. Ie, we will have the right primitives to make such behaviour implementable. > A week later, you walk up to a different workstation in the cluster, > and pop in your disk. The system says, "I notice you have a suspended > job that was using this disk for swap space" and allows you to resume > it where you left off. (Notice that this requires close interaction > between the workstations in the cluster, combined with more > driver-level cleverness.) Well, that's now entering the realm of pipe dreams ;) > Now that's a well-functioning system. Only within a very specific set of administration policy. I agree with the essence of your writing though that the assumed underlying operating system primitives which allow to express such semantics are desirable. Some of this is already part of our agenda for the Hurd on L4. Although I have to say that writing all the shitty code that would be necessary to make all the interactions work in the way you describe it is _not_ part of our agenda ;) That can be left to other people, who can implement it completely in user space. > It requires careful bookkeeping > of context, knowledge about how to usefully interact with the user > from deep in the bowels of the system, Our plan is to move more of the bowels of the system to the user. > The reason that filesystems do not have user context is because I was > not sufficiently far-sighted at the time to realize the full > flexibility of the translator concept I had created. Now that we know > more about that flexibility, it would be nice to start figuring out > how to improve it. There is certainly a wealth of cool stuff out there to find by exploring into this direction. However, I would also suggest looking into another direction: Move more of the functionality outside of the system services, and into the user's own code. In the cases where this is possible it has benefits in important areas like resource control and accounting, performance (make decisions there where most information is available) and security. Well, the details can't be discussed in the abstract. For user-interaction, it matters a lot what you do in which context. I think each case must be looked at individually. I also want to put a strong emphasis on security. The Hurd lacks it in sometimes a quite fundamental way. Luckily, fixing these problems does not take away much from the Hurd, quite the opposite: By enforcing tighter security rules, even more code gets pushed into the user space, and outside the system code. Well, there are always some drawbacks. At least in some instances we have to raise the barrier for user's sharing resources accidentially. For example, I am strictly against following translators being followed by default, if they are not installed on a node owned by a trusted user (root, system users, yourself, and your friends). Following untrusted translators in the filesystem is a real security hazard. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
