docker-openldap icon indicating copy to clipboard operation
docker-openldap copied to clipboard

chown missing on TLS_CA_CRT_FILENAME

Open janpolito opened this issue 3 years ago • 5 comments

Summary

When ENABLE_TLS is TRUE, we get a permission denied on TLS_CA_CRT_FILENAME loading during TLS negociation.

Steps to reproduce

Set ENABLE_TLS to TRUE, make sure you have your certificates on the server, run a ldapsearch on ldaps

What is the expected correct behavior?

Succesful ldapsearch

Relevant logs and/or screenshots

Sorry, no logs.

Environment

  • Image version / tag: tiredofit/openldap version 7.1.16
  • Host OS: CentOS 8

Possible fixes

A possible workaround is to run "docker exec -it openldap chown ldap:ldap $TLS_CA_CRT_FILENAME" right after container startup.

janpolito avatar May 31 '21 07:05 janpolito

Have you tried the environment variable $TLS_RESET_PERMISSIONS=TRUE ?

tiredofit avatar May 31 '21 13:05 tiredofit

This var was not set in my initial configuration. I added it but same error: TLS: could not load verify locations .. TLS: error:0200100D:system library:fopen:Permission denied crypto/bio/bss_file.c:69

janpolito avatar Jun 01 '21 09:06 janpolito

Can you tell me the permissions of the files when they are outside of the container, and inside of the container? I don't think this is an image problem itself, more so docker translation of the two layers messing this up. We fixed this quite a long time ago, and then also added that variable above (TRUE/FALSE) to solve some issues that crept up for people who didn't want to have the permissions changed.

Your approach with on container startup will work as well, this image is extendable to do that sort of thing by adding a bash script in /assets/custom-scripts/ to perform your chmod/chown function. That would be a last resort though. Is there something from another container changing the permissiosn of the certificates as well?

tiredofit avatar Jun 01 '21 14:06 tiredofit

We used tiredofit/openldap version 6.6.1 and no such issue. Moving to 7.1.16 we falled in this problem. Without the workaround, the file is in root:root in both container and host. This host is dedicated to LDAP, nothing else running (just tiredofit/openldap-fusiondirectory:7.0.4 and tiredofit/fusiondirectory:2.6.2).

janpolito avatar Jun 03 '21 11:06 janpolito

Right, so something definitely changed in the image from 6.6.1 to 7.1.16.

See ver 6.8.0:

   ### Added
      - Environment Variables to control keysize of DH Param file
      - New variables to define custom TLS Patches
      - New variables to skip changing ownership on TLS Certificates

Then 6.8.2

   ### Changed
      - Fixed spelling mistake for OpenLDAP version

Of course 7.x.x was a major release and I changed a whole bunch of TLS settings as well. Theoretically this should work, I am having real troubles trying to replicate this on my end.

See the thread that prompted the change here: #17

tiredofit avatar Jun 03 '21 14:06 tiredofit