docker-compose fails to run CodeChecker server with permission denied

[andrewg-spectra]

Describe the bug
docker-compose files that mount a workspace volume to /workspace will create that directory when the service container is created. That directory will always have owner root. The entrypoint.sh script will see that the /workspace directory exists and not run chown codechecker on it. However, CodeChecker server when run as user codechecker needs to be the owner of /workspace to write to it.

CodeChecker version
v6.17.0

To Reproduce
Run docker-compose up on any of the sample files. You may need to change the image to codechecker/codechecker-web:v6.17.0

Expected behaviour
codechecker service should initialize correctly.

Desktop (please complete the following information)

• OS: Linux
• Browser: N/A
• Version: N/A

Additional context
None.

[csordasmarton]

If you do not mount a workspace directory, and you run a CodeChecker container with a default user (root) and the default entry point the container will do the following steps:

• It will create a workspace directory.
• Change the permission of this folder to codechecker user.
• Run the CodeChecker server command with the codechecker user.

Second use case is that when you mount a directory for /workspace. In this case the directory permissions are controlled by the host system and we do not change it inside the container. The problem is the following: lets assume that you are using a separate drive (e.g.: NFS storage) to save CodeChecker data and only myuser has write permission to this drive. In this case if you would run a CodeChecker container with the default user but a mounted workspace and the container would change the permission to the codechecker user you would get error inside the container that codechecker user doesn't have permission to write to the workspace directory.

So if you want to mount a directory to the /workspace directory the permissions must be controlled on the host machine and you can always run the container with different users by using the --user option of the docker run command or user option in the compose file.

[andrewg-spectra]

@csordasmarton For the sake of this discussion, I am using a third use case as documented. I am using docker-compose in a fresh environment with no pre-existing volumes. docker-compose has docker create an empty docker volume and mounts it to /workspace. Such a directory does not exist in the docker image itself so it creates it with owner root. I found no way to configure the owner of the mount directory through docker (e.g. setting user: codechecker does not work).

For this use case, the problem is the default entry point script does not change the owner of the workspace directory because it already exists. Thats because docker automatically created the workspace directory to mount the volume while setting up the container.

[aallrd]

I think I am hitting the same issue using the simple docker run example from the documentation:

$ docker run --rm -p 8001:8001 -v /home/$USER/codechecker/workspace:/workspace codechecker/codechecker-web:6.18.0
[INFO 2021-11-29 14:48] - Checking configuration database ...
[INFO 2021-11-29 14:48] - Connection failed to the database server.
[ERROR 2021-11-29 14:48] - Failed to configure default product

Same thing when not bind-mounting:

$ docker run --rm -p 8001:8001 -v codechecker_workspace:/workspace codechecker/codechecker-web:6.18.0
[INFO 2021-11-29 14:49] - Checking configuration database ...
[INFO 2021-11-29 14:49] - Connection failed to the database server.
[ERROR 2021-11-29 14:49] - Failed to configure default product

I reproduce this issue starting release 6.17.0.

Successful output with 6.16.0:

docker run --rm -p 8001:8001 -v codechecker_workspace:/workspace codechecker/codechecker-web:6.16.0
[INFO 2021-11-29 14:51] - Checking configuration database ...
[INFO 2021-11-29 14:51] - Database schema is missing.
[INFO 2021-11-29 14:51] - Product 'Default' at '/workspace/Default.sqlite' created and set up.
[INFO 2021-11-29 14:51] - Status of products:
---------------------------------------------------------------------------------------------------------------------------------------
Product endpoint | Database status         | Database location         | Schema version in the database | Schema version in the package
---------------------------------------------------------------------------------------------------------------------------------------
Default          | Database is up to date. | /workspace/Default.sqlite | dabc6998b8f0 (up to date)      | dabc6998b8f0
---------------------------------------------------------------------------------------------------------------------------------------
[WARNING 2021-11-29 14:51] - Server started without 'root.user' present in CONFIG_DIRECTORY!
[INFO 2021-11-29 14:51] - A NEW superuser credential was generated for the server. This information IS SAVED, thus subsequent server starts WILL use these credentials. You WILL NOT get to see the credentials again, so MAKE SURE YOU REMEMBER THIS LOGIN!
[INFO 2021-11-29 14:51] - -----------------------------------------------------------------
[INFO 2021-11-29 14:51] - The superuser's username is 'CIUSYT' with the password '9a1aa4d1'
[INFO 2021-11-29 14:51] - -----------------------------------------------------------------
[INFO 2021-11-29 14:51] - CodeChecker server's example configuration file created at '/workspace/server_config.json'
[WARNING 2021-11-29 14:51] - '/workspace/server_config.json' is readable by users other than you! This poses a risk of leaking sensitive information, such as passwords, session tokens, etc.!
Please 'chmod 0600 /workspace/server_config.json' so only you can access the file.
[INFO 2021-11-29 14:51] - Garbage collection for product 'Default' started...
[INFO 2021-11-29 14:51] - Garbage collection finished.
[INFO 2021-11-29 14:51] - Searching for SSL key at /workspace/key.pem, cert at /workspace/cert.pem, not found...
[INFO 2021-11-29 14:51] - Falling back to simple, insecure HTTP.
[INFO 2021-11-29 14:51] - Server waiting for client requests on [[::]:8001]

[andreas-foreflight]

+1

It seems to me that the approach of using a volume as described in the documentation no longer works since version 6.17 where the entrypoint script was changed to allow running as different users.