Suggestions (~wishlist)

[Lee Winter]

On Fri, Sep 18, 2009 at 12:55 AM, Teddy Hogeborn <teddy at fukt.bsnet.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lee Winter <lee.j.i.winter at gmail.com> writes:
>
>>> I suppose we could write a Mandos plugin which in turn runs
>>> "passdev", but [...]  If this is what someone wanted, wouldn't they
>>> just use "passdev" *instead* of Mandos?
>>
>> No, because plugging in the device is an alternative to mandos not a
>> replacement.  Just as manually typing in a password is an
>> alternative rather than a replacement for mandos.
>>
>> Operationally the passdev is a replacement for manually typing in a
>> password.
>
> I see your point.  All right, writing a small plugin to call passdev
> shouldn't be very hard; I'll look into it.
>
>>> Yes, this was also what I thought at first, but then I realized
>>> that providing notifications via D-Bus was cleaner and more
>>> flexible. [...]
>>
>> [...] I disagree.  D-Bus is clearly much more powerful.  But that
>> power comes at a very high cost.
>
> This is true.
>
>> I have not looked at D-Bus adapters yet, so something like what I
>> envision may already exist.  But it not you may decide to add it as
>> a default/example D-Bus client.
>>
>> If the primary notification mechanism is D-Bus I predict substantial
>> demand for a D-Bus client that would just provide a shell/exec/
>> spawn/system() type of capability for a main event, which is a key
>> request.
>
> I was trying to delude myself to think that we wouldn't have to write
> such programs, to make it all seem manageable, but you're right, of
> course; such a program would be useful, and probably rather easy to
> write once we've gotten the hang of D-Bus, which we will need to do
> anyway.  Added to TODO file.

You could put this on low priority and if no demand develops it never
needs to get done.

>>>>         4. Ask permission*, impatiently pessimist (negative
>>>>            timeout = no operator action -> disable client)
>>>
>>> I don't see the point of this - couldn't the client just be
>>> disabled, and the operator could then enable it when desired?
>>
>> This exists to handle a specific issue.
>
> I understand the issue, but I just think that the existing (or rather
> planned) code can provide functionally equivalent behavior:  If a
> client is set to need manual approval and is hanging in this state,
> this is functionally equivalent to what you propose.

I think you intend to reduce mode 4 to mode 3, which results in the
client waiting forever but does not change the state of the slient's
permissions or mode on the server.  In many cases that is a valid
simplification.  But even if mode 4 is never implemented please
maintain it as a conceptual alternative so that the distinction
between the casses 3 & 4 are not obscured during later design phases.

>
>> I think you could consider it an issue of completeness.
>
> The server is complicated enough as it is, I'll need a good reason for
> a feature being needed before implementing it.  In my opinion, just
> "completeness" is not a good enough reason.

Understood.

> Patches are always welcome, of course.  :)

Yeah well, I'm interested enough to put contributions to mandos on my
to do list, but I have to find the end of it, which is buried somwhere
in the sedimentary (f|p)iling system underwhich lies my desk.
Someday.

>> I may not have described the modes clearly enough.  All of the mode
>> variables are on the server.  [...]
>
> Oh, I get it now.  Thanks.
>
>> Again I should have been more specific.  Try this: "rebooting a client
>> should have no effect upon the operating mode that the server has
>> associated with that client".  I.e., I am sugesting that no action of
>> the client should alter anything on the server.
>
> Right, I see.  This is already the case, of course, and I've no plans
> to change this.

Good.

You have a good system for the HOW of centralized boot key management.
 I hope you do as well on the WHEN (and when not) of it.

-- Lee