Re: heads up

[Marcus Brinkmann]

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