chown fails with Docker Secrets, can't start container

[adammcmaster]

passbolt_docker/bin/docker-entrypoint.sh

Line 170 in f212767

chown -R nginx:nginx /var/www/passbolt

The above line fails when starting Passbolt with config files stored in Docker Secrets:

chown: changing ownership of '/var/www/passbolt/app/Config/gpg/serverkey.asc': Read-only file system
chown: changing ownership of '/var/www/passbolt/app/Config/gpg/serverkey.private.asc': Read-only file system
chown: changing ownership of '/var/www/passbolt/app/Config/database.php': Read-only file system
chown: changing ownership of '/var/www/passbolt/app/Config/email.php': Read-only file system

[dlen]

Hi @astopy thanks for your report!

Yeah this permission change was introduced to fix #67 since some users were experiencing problems when mounting external directories.
For v2 we are enforcing users to work with environment variables instead of mounting files (except for serverkeys) so the container matches more what an user expects to be a "cloud native application".
There are two options I can think of here to fix your problem on v1.6:

• Check for filesystem permissions on configuration files and change ownership only if missing/not correct. This leads to slower container startup times.
• Do not make ownership changes (remove the check_permissions()) and leave it to the user's responsibility to provide correct permissions on mounted files.

We would like to hear some feedback here on what community thinks about this.

[adammcmaster]

For v2 we are enforcing users to work with environment variables instead of mounting files (except for serverkeys) so the container matches more what an user expects to be a "cloud native application".

That could be a problem for Docker Swarm users because there's no way to expose secrets as environment variables (I believe that's a deliberate design choice on the part of the Docker team). A workaround I've used in some other apps is to have the entrypoint script check for a file (e.g /run/secrets/environment) and source it if it exists.

There are two options I can think of here to fix your problem on v1.6:

My preference would be for the second option. I wouldn't expect a container to change permissions and ownership on config files that I mount into it.

[dlen]

Thanks for your feedback it is really appreciated!

That could be a problem for Docker Swarm users because there's no way to expose secrets as environment variables (I believe that's a deliberate design choice on the part of the Docker team). A workaround I've used in some other apps is to have the entrypoint script check for a file (e.g /run/secrets/environment) and source it if it exists.

Yeah it's to avoid anyone to get the secrets inspecting the running process environment inside the container (or just doing docker inspect).
It might be interesting to add, as an example, some env variables with the suffix "_FILE" for the cases where the data is sensitive and thus will be loaded as a secret. I can think now about use cases of this for database credentials and email credentials. Providing for instance a DATASOURCES_DEFAULT_PASSWORD_FILE that contains the path of the secret would solve the use cases of the major container services (swarm, k8s...)

[adammcmaster]

Yes, actually, now that you mention it I think that'd be the best option. That'd be consistent with what some of the official images do (e.g. MySQL).

[dlen]

Yes! We will try to push this up on the backlog for the v2 sounds like an accepted approach in the container community.
Thanks again for the feedback is well appreciated!

[radyz]

Do we have to option to use _FILE variables with docker secrets yet? I pulled version 2.2.0 but I can't find anything in docs yet regarding using docker secrets in swarm mode.

Thanks

[dlen]

Hi @radyz,

Unfortunately there is no option to manage _FILE variables with docker secrets at this moment. However this issue it's on the backlog and will be tackled soon.

[radyz]

Thanks for your quick update. I'll be looking forward for it when it's released then :)

[lucasteinke]

Unfortunately there is no option to manage _FILE variables with docker secrets at this moment. However this issue it's on the backlog and will be tackled soon.

Can I open an Issue in this repository to track that? I don't see anything in https://community.passbolt.com/c/backlog either.

[brettdh]

@dlen @lucasteinke I couldn't find anything in the backlog either, so I added this: https://community.passbolt.com/t/as-a-swarm-k8s-administrator-i-want-to-configure-passbolt-with-path-to-db-password-file-to-use-my-orchestration-tools-built-in-secrets-store/5222/1