When doing client cert based authentication for replication or chaining, and attrcrypt attempts to find the server's cert and key, it can get confused and attempt to use the wrong key. Apparently in openldap's NSS implementation, the cert can end up on a token that has not been logged out, and the server will try to read the pin for the token/slot on stdin.
Do we need to check if slot is NULL before calling PK11_IsLoggedIn() here?:
{{{ PK11SlotInfo *slot = sle->slot; if (PK11_IsLoggedIn(slot, pin_arg)) { }}}
Where we log cert->subjectName, should we check if it is NULL first by doing this?:
{{{ slapi_log_error(SLAPI_LOG_TRACE, "slapd_get_unlocked_key_for_cert", "Skipping locked slot [%s] token [%s] for certificate [%s]\n", PK11_GetSlotName(slot), PK11_GetTokenName(slot), cert->subjectName ? cert->subjectName : "null"); }}}
Do we also need to check if PK11_GetSlotName() and PK11_GetTokenName() return NULL before trying to log their return values? It seems unlikely, but the NSS code just returns whatever is in the slot struct, which might be NULL.
Aside from those minor nit-picks, the patch looks good.
0001-Ticket-47596-attrcrypt-fails-to-find-unlocked-key.patch 0001-Ticket-47596-attrcrypt-fails-to-find-unlocked-key.patch
To ssh://git.fedorahosted.org/git/389/ds.git bd0efbd..1b74654 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 1b74654 Author: Rich Megginson rmeggins@redhat.com Date: Fri Nov 15 10:24:26 2013 -0700 20b8c33..e2d1107 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 commit e2d1107 Author: Rich Megginson rmeggins@redhat.com Date: Fri Nov 15 10:24:26 2013 -0700 da9fed7..92b4629 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 92b4629 Author: Rich Megginson rmeggins@redhat.com Date: Fri Nov 15 10:24:26 2013 -0700 17e5d8a..cf091de 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit cf091de Author: Rich Megginson rmeggins@redhat.com Date: Fri Nov 15 10:24:26 2013 -0700 5027211..b1fad4e master -> master commit b1fad4e Author: Rich Megginson rmeggins@redhat.com Date: Fri Nov 15 10:24:26 2013 -0700
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1032315
To ssh://git.fedorahosted.org/git/389/ds.git 02530c8..326d636 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 326d636 Author: Rich Megginson rmeggins@redhat.com Date: Tue Nov 26 08:14:07 2013 -0700 0ef6eff..33df11e 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 commit 33df11ea7a9cbef5f78fe0d43da8a1c77b0a6c98 Author: Rich Megginson rmeggins@redhat.com Date: Tue Nov 26 08:14:07 2013 -0700 1d2b28d..5d2a20b 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 5d2a20b Author: Rich Megginson rmeggins@redhat.com Date: Tue Nov 26 08:14:07 2013 -0700 924ead4..f608a94 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit f608a94 Author: Rich Megginson rmeggins@redhat.com Date: Tue Nov 26 08:14:07 2013 -0700 3a6ce92..e66c4ce master -> master commit e66c4ce Author: Rich Megginson rmeggins@redhat.com Date: Tue Nov 26 08:14:07 2013 -0700
Metadata Update from @rmeggins: - Issue assigned to rmeggins - Issue set to the milestone: 1.2.11.26
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/933
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.