Issue with password hashes for `openldap:2.6.10-alpha`

[Chaostheorie]

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.

[BertrandGouny]

Nice catch, thanks!

I think the issue comes from the .env handling, 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]

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:

• document that escaping is required or
• accept a file path as input instead and load the hashed value from there

The former might be enough if the DX of manually escaped values is fine.