excessive log warnings during certificate extraction

[Firstyear]

Issue Description
A customer noticed repeated bursts of warnings from check_private_certdir() during operation of a 389-ds container. This occurs because in the container, tmp is not a system private mount, causing the check to return NULL.

While this itself isn't a problem since there is a valid fallback to certdir as the extraction path, the excesive log noise indicates that we are calling https://github.com/389ds/389-ds-base/blob/main/ldap/servers/slapd/ssl.c#L2201 in a loop, when certdir should be defined once at the time of extraction.

Realistically we should be extracting setting the cert/key paths during extraction https://github.com/389ds/389-ds-base/blob/main/ldap/servers/slapd/ssl.c#L2505 rather than calculating it each time we perform the loop of ssl client auth.

Package Version and Platform:

• SUSE 15 SP5

https://bugzilla.suse.com/show_bug.cgi?id=1230852

[Firstyear]

@tbordaz I think you were the last person to touch this code from memory, what do you think?

[Firstyear]

@progier389 @droideck What do you think about this? I'm happy to make the change.

[tbordaz]

@Firstyear , sorry I missed your ping. I was not able to see the log from bugzilla but ATM I assume it displays warning (from check_private_certdir) because tmp is not a private namespace.
I agree that checking/building the certdir path at each auth looks a bad idea. It should be done once, when extracting the cert/key then stored somewhere.

[Firstyear]

@tbordaz I think the problem is 'where' we should store it.

The problem I think is when we use slapd_SSL_client_auth on 2075 of ssl.c / slapd_SSL_client_auth() we iterate over the "family list" which appears to be the list of p11 tokens available. My concern is if there is a server with multiple tokens, how this is handled.

Today I think we just take the "last token in the list" because it doesn't seem like there is a way to break from that loop if there are multiple. So I'm guessing that my worry here is not a problem in reality.

If we assume that we only have one token, then we can just set a global during slapd_ssl_init() which is where the extraction is done, and then we can consume it in slapd_SSL_client_auth since both of these have the same token iteration problem.