[Opendnssec-develop] PIN daemon

Rickard Bellgrim rickard at opendnssec.org
Tue Aug 30 14:21:36 UTC 2011


> The second name confuses me.
> Blocking a PIN sounds like making it unusable on the token.
> May I suggest a name like hsm_await_pin() instead?

Yes

> Should there not be a function hsm_forget_pin() as well?
> I can imagine an operator wanting to do this without having
> to resort to SYSV cmdline tools that forget to clear the
> shared memory before setting it free!  The matching control
> operation would be called "logout" I suppose.

That would be good. I would suggest a forth mode HSM_PIN_FORGET.

>> - "mode" is the type of mode the function should run in.
>
> It is an enumerated value, right, not a set of OR-ed flags?

Yes, enumerated value.

>> hsm_prompt_pin() + HSM_PIN_FIRST = Return the PIN from the shared
>> memory if there is one. If not, then prompt for one.
>> hsm_prompt_pin() + HSM_PIN_RETRY = Prompt and return a PIN.
>> hsm_prompt_pin() + HSM_PIN_SAVE = If we have prompted for a PIN, then
>> save it in the shared memory.
>
> Shouldn't you speak in terms of the PIN daemon with these flags?
> That is, _MAY_PROMPT for _FIRST and _MUST_PROMPT for _RETRY?
> Instead of hsm_prompt_pin() I would use a name hsm_retrieve_pin().

hsm_prompt_pin() is the current PIN callback function provided by
libhsm. Jakob wanted to know if the PIN daemon could be implemented as
PIN callback function. To use getpass/getpassphrase, you need to run
in the foreground. But we also have processes running in the
background. Two simplify it, we provide two functions. One who can
prompt for the PIN and the other who will wait for it to appear in the
memory.

And as I said, HSM_PIN_FIRST will first see if the PIN is cached
before prompting for it.

> In the _SAVE's explanation, "we" would best be the same process,
> in order to avoid DoS risks by other processes running it to
> confuse our process.

Yes, that would only be local.

> Is it not clearer to have a separate hsm_save_pin() function
> instead of a "mode" in a function called hsm_prompt_pin()?

The application initiate libhsm by proving a PIN callback function, so
we only have one function to call.

>> The daemons would initialize libhsm with the hsm_block_pin() and the
>> other applications would use hsm_prompt_pin().
>
> What happens if multiple calls from "other applications" try to get
> the PIN entered at the same time?  I suspect it'll work, but it is
> worth some explicit attention.

If you run hsm_prompt_pin() from two different shells (remember that
we need a foreground process) at the same time, then both will ask for
the PIN if there is none in the shared memory. Both will login with
the PIN. And both will save the PIN in the shared memory if the login
was successful. (Still using the named semaphore)

// Rickard



More information about the Opendnssec-develop mailing list