[dm-crypt] Shared library for cryptsetup

[Teddy Hogeborn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jürgen Pabel <jpabel at akkaya.de> writes:

> Adding a dedicated tokentube plugin is a no-go because there would
> be no dedicated/unique input mechanism for tokentube (it would need
> to communicate either via console, fifo, usplash or splashy and thus
> collide with the other plugins).

I still feel like this is the way to go - the problem is collision of
use of the console and usplash, but I feel this should be solvable.
The TokenTube plugin could somehow signal to the plugin runner that
TokenTube is also using the console and usplash and that it's also
more important than other plugins, and the plugin runner could be made
to respect this and not start the conflicting plugins.  See below for
more on this idea.

An interim solution (if one would want some solution relatively
quickly) would be to write a normal Mandos plugin for TokenTube but
require the user to configure the plugin runner to not run the
"password-prompt" and "usplash" plugins, to avoid collisions.

> A possible solution would be to change tokentube's implementation:
> instead of extending debian's askpass, I could implement a new input
> interface for tokentube and have someone implement a corresponding
> plugin for mandos. I don't really like this approach - however, I
> think it's a viable solution if nothing better comes along.

I agree; I don't really like this approach, either.

> A seemingly practical approach would be to modify the "local" mandos
> plugins (prompt, fifo, splashy & usplash) to detect whether
> tokentube is installed [...].  I don't like this approach because it
> requires too much tokentube-related logic in mandos - but if you are
> OK with it then I am too.

No, I don't like that - they say a little knowledge is a dangerous
thing, and I believe this applies to software, too.  Knowing things
about external systems is, in effect, an API to the outside, and APIs
should be kept simple.

> Comments or other ideas?

Here's my thinking:  Both Mandos (the client-side network-
communicating part) and TokenTube both want the same thing: to get a
chance to supply the password.  Since the Mandos client may or may not
get a password (or it may take some time), it needs to run in parallel
to others which want to provide it, like TokenTube or some simple
password prompt.  This is what we wrote the Mandos plugin system to
do; it runs all of its plugins in parallel and allows any one of them
which exits with a successful exit code to provide the password.  The
problem we now face is one of resource contention.  This was never an
issue with any of our plugins; the "mandos-client" plugin uses only
the network, the "password-prompt" plugin uses only stdin and stderr,
the "usplash" plugin was the only one using usplash, etc.  But this, I
feel, is the problem to solve.  It shouldn't even be that difficult;
other systems must have faced similar situations before.

As I see it, plugins could be made to say what resources to use, so
that the plugin runner could avoid collisions, and plugins should also
supply a priority, so that the plugin-runner can choose predictably
between plugins competing for the same resource.  This information
must also not be static, since (for example) a theoretical "tokentube"
plugin does not know if it will be running until it can check whether
a TokenTube system is there to communicate with.  It's also somewhat
important to us to be backwards-compatible with old plugins (since
Mandos was released a year ago and accompanied the Ubuntu release five
months ago).

So, here's a possible implementation of this:  The plugin runner is
changed thus:
1. It starts all plugins in strictly alphabetical (strcmp) order.
2. If the file name of the current plugin begins with a number:
   a) Start the plugin with an extra file descriptor, numbered 3,
      opened, which is a pipe to the plugin runner.
   b) BEFORE STARTING THE NEXT PLUGIN, read from the plugin's FD 3.
      There, the plugin is supposed to write, in some well-defined
      format (like a space-separated list of strings), what resources
      it will *actually* use, *before* it has begun to use them.
   c) If a resource conflict is detected, the plugin is killed.

I'm sure this idea is horrible, but it would solve the stated
requirements.  Surely we can come up with something better than this
if we give it some thought.

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKvhaPOWBmT5XqI90RAoF1AJ41xUZe32ZMROhnmwM+9PWWfFHszwCg3Oc4
+oD+x7o6MAKK1XOCryHuW0U=
=/zDc
-----END PGP SIGNATURE-----