Repository navigation
Issue with password hashes for openldap:2.6.10-alpha #704
Description
Hey, thank you for your continued work on providing a container image for OpenLDAP.
I’m currently building a testcontainers wrapper around this image to test against/mock OpenLDAP 2.x, but there seems to be a issue with hash handling during bootstrap in openldap:2.6.10-alpha (image digest sha256:fb0e84e744d54135ae1bb9b0f34d858b4219830c3f0536819f505ebe7a5d3918).
Specifically, it appears that environment variables are reparsed at some point, causing $ characters in their values to be interpreted as variable references.
For example, passing the following environment variable:
OPENLDAP_BOOTSTRAP_DATA_ROOT_PASSWORD_HASHED={ARGON2}$argon2id$v=19$m=65536,t=3,p=4$pHysLBm/kFPLuIQaKZUdIw$J9K+g6AIsHumbrjHiKBL3+aIVYAa+mBl3KNDiFiYVHA
results in the following database value, as reported by slapcat -n 0 inside the running container:
olcRootDN: cn=admin,[my prefix]
olcRootPW:: e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MyxwPTQkcEh5c0xCbS9rRlBMdUlRYUtaVWRJdytnNkFJc0h1bWJyakhpS0JMMythSVZZQWErbUJsM\
0tORGlGaVlWSEE=
This decodes to:
{ARGON2}$argon2id$v=19$m=7168,t=5,p=1$cX6Fzhw//Y4fL4q1iI3gEA$KGbo9cKg8CMCEsPoooLp4UQaPAub8rUiubRma3VpIdw
The problem is more clearly visible when comparing the expected and stored values:
{ARGON2}$argon2id$v=19$m=65536,t=3,p=4$pHysLBm/kFPLuIQaKZUdIw$J9K+g6AIsHumbrjHiKBL3+aIVYAa+mBl3KNDiFiYVHA
{ARGON2}$argon2id$v=19$m=65536,t=3,p=4$pHysLBm/kFPLuIQaKZUdIw+g6AIsHumbrjHiKBL3+aIVYAa+mBl3KNDiFiYVHA
It appears that $J9K is being interpreted and removed. This corrupts the digest by removing the separator between the salt and the hash.
My current workaround is to escape every $ character as \$:
strings.ReplaceAll(digest, "$", "\\$")This resolves the issue for now.
Unfortunately, I haven’t been able to determine exactly where this happens in the bootstrap code. It appears to originate somewhere in the helper scripts provided by the base image.
Activity
BertrandGouny commentedon Aug 24, 2026
Nice catch, thanks!
I think the issue comes from the
.envhandling, which probably expands variables and replaces them with their values in the base image, around here:https://github.com/osixia/container-baseimage/blob/9e9b0a8cde719f98539b374d18daee97c38ecbe4/core/filesystem.go#L148
I'm not quite sure what the best way to fix this would be, so any suggestions or contributions are very welcome.
Chaostheorie commentedon Aug 24, 2026
Thank you for digging into it. I lack the knowledge of the codebase to understand if this (re)substitution is used elsewhere but at least a somewhat short term fix might be to either to:
The former might be enough if the DX of manually escaped values is fine.
BertrandGouny commentedon Oct 7, 2026
Following up on my earlier comment: I’ve updated the base image’s
.envhandling, and the fix will be included in the next RC.The loader previously restored existing environment variables using
gotenv.OverApply, which parsed their values again and could interpret parts of a password hash as variable references.Existing environment variables are now preserved literally and remain the highest priority, including when empty. Hashes passed directly to the container will no longer need the extra
\$escaping workaround.Interpolation inside
.envfiles and their override order are unchanged. In those files, literal$references still need escaping or single quotes. Explicit expansion withcontainer envsubstalso remains unchanged.The documentation has been updated to clarify this behavior. Shell or Docker Compose escaping may still be necessary before values reach the container.
BertrandGouny commentedon Oct 7, 2026
Thanks for the clear example and for sharing your workaround. The bootstrap issue that corrupted password hashes containing
$characters has been fixed in2.6.15-alpha.Please try
osixia/openldap:2.6.15-alphawith the original hash passed directly through your testcontainers environment, without the extra backslash-escaping workaround. Closing this as resolved; feel free to reopen it if the stored hash still differs from the supplied value.Chaostheorie commentedon Oct 18, 2026
Thank you for fixing this bug, I hope this helps to eventually get your new LDAP image out of alpha phase. Due to some other issues (mostly with our testing infra) we changed to another LDAP image, so unfortunately I cannot easily reproduce/verify this anymore.