[Opendnssec-develop] Merge OpenDNSSEC-pin2 into trunk

Jerry Lundström jerry at opendnssec.org
Tue Aug 28 08:52:43 UTC 2012

On Aug 28, 2012, at 10:26 , Rickard Bellgrim wrote:
>> - Do we need to check the size of the shared memory returned?
>> It does not specify what happens if there already is a share memory segment and its a different size then what you specify in shmget(), might be good to check the size if it might have been changed between compilation/version etc.
> If there is a memory segment but it is smaller than the given size,
> then shmget will fail with the error EINVAL. This will happen if we
> increase HSM_MAX_SESSIONS or HSM_MAX_PIN_LENGTH. The memory segment
> would need to be destroyed with the command below. I can add a comment
> about this in the code, so that we remember this in future releases.
> If we decrease HSM_MAX_SESSIONS or HSM_MAX_PIN_LENGTH, then the
> alignment in any existing memory would be wrong. Thus a bad PIN will
> be given back to the code. The code is however written so that the PIN
> will be removed from the shared memory if it causes a failed login
> attempt.

I think it would be better to not touch that memory area if the size miss match since otherwise you might corrupt the memory of a running daemon if you recompiled/installed a new version and did not migrate correctly.

>> - Tools to destroy/recreate the share memory segment?
>> As in above if the share memory segment is changed between versions/compilations then for migration there might be good if there is a tool to recreate or destroy the segment. And it might be something some sysadmins want.
> For now it is:
> ipcrm -M 0x0d50d5ec

Okey, just thought it would be nice for the users to have a ods-hsmutil clear-login command so they don't have to know about the segment key.

>> - Not save the pin?
>> If I see it correctly the pin is saved in shared memory whether you want it or not, maybe this should be an option for the paranoid?
> If it is not saved in the shared memory, then it will not propagate to
> the daemons which are waiting for the PIN to appear.

Ah, I read the code wrong, sorry.

One more thing.

When it does hsm_open() and use the hsm_pin_block() callback it will block until there is a pin in memory and that code it before it creates a pid and other stuff. This might be problematically since the user can start multiple and he/she might not understand why its not starting up, I also wonder what happens to the start up scripts if there is no pin in memory, just hangs?

Would be good with some syslog messages also "I am waiting on pin…" etc.


Jerry Lundström - OpenDNSSEC Developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20120828/d23e74b1/attachment.bin>

More information about the Opendnssec-develop mailing list