Learn more about these different git repos.
Other Git URLs
softhsm stores tokens and other information in /var/lib/softhsm/tokens/<id>
If the token is owned by a specific user then renewing, and likely requesting, a certificate in certmonger will result in bad permissions on the token files making the new certificate unavailable to the end user.
For example, using softhsm as a HSM for the CA in IPA. All files in the token should be owned by the user pkiuser. Forcing a renewal of a certificate will issue the new certificate but since certmonger opens the NSS database as root the file is written out owned by root, therefore unavailable to pkiuser.
I think the fix is to setuid/gid to the database owner/group. Calling initgroups() is also required because /var/lib/softhsm is owned by the group ods in IPA, of which pkiuser is a member.
This is going to require tracking changes in IPA as well. And will have freeipa-healthcheck implications also.
Addressing this leads to additional issues. The token is not well-considered when certmonger tries to clean up existing certificates.
The certificate will appear in the softokn NSS database as well because that is where the trust is stored. There is already slot comparison done in certsave-n.c but it looks like the nickname comparison is off, comparing the raw nickname with the token + nickname.
I attempted to wrap the dogtag-agent-submit CA with runuser -u pkiuser -- but it blows up in several ways:
runuser -u pkiuser --
The last one is the deal breaker. A better solution looks to be to handle the setuid/gid as a property. The open question is add a new property or overload an existing one, like key-owner? Specifically for NSS, key-owner chown()s the key database (key3.db, key4.db, etc). So re-using it to switch the user seems ok, maybe. The difference may be in the first use of an existing database owned by some other entry because the ownership is set after the cert is saved. So switching to the user while saving could fail because it doesn't yet own it.
chown()
master: 7c75490
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.