Suggestions (~wishlist)

[Teddy Hogeborn]

-----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.

>>>         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 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.  Patches are always
welcome, of course.  :)

> 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.

> I hope this clarifies the confusing parts of my suggestions.

It did.  Thank you!

/Teddy Hogeborn

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

iD8DBQFKsxLaOWBmT5XqI90RAkZzAJ9SphF0Gz6dymdtAXLRFyMZAJU7UwCfSBVN
5tMR1cdzDrUxayb439nRxms=
=tRRe
-----END PGP SIGNATURE-----