Closed Jgigantino31 closed 3 months ago
It appears I might have a permissions issue. Setting PUID and GUID to 0 in my docker compose file allows all the services to start. The permissions of the modified Core.dll in API and Identity appear to be off compared to an unmodified Core.dll.
Docker container logs:
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,795 INFO success: sso entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,795 INFO success: notifications entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,795 INFO success: nginx entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,795 INFO success: icons entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,794 INFO success: events entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,794 INFO success: api entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,794 INFO success: admin entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:50:14 | stdout | 2024-07-26 18:50:14,793 INFO success: identity entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,723 INFO spawned: 'sso' with pid 48
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,721 INFO spawned: 'notifications' with pid 47
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,715 INFO spawned: 'nginx' with pid 46
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,711 INFO spawned: 'icons' with pid 45
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,709 INFO spawned: 'events' with pid 44
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,707 INFO spawned: 'api' with pid 43
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,705 INFO spawned: 'admin' with pid 42
2024/07/26 14:49:59 | stdout | 2024-07-26 18:49:59,702 INFO spawned: 'identity' with pid 41
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,699 INFO supervisord started with pid 1
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,699 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,699 INFO RPC interface 'supervisor' initialized
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/sso.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/scim.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/notifications.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/nginx.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/identity.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/icons.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/events.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/api.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 INFO Included extra file "/etc/supervisor.d/admin.ini" during parsing
2024/07/26 14:49:58 | stdout | 2024-07-26 18:49:58,693 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
2024/07/26 14:49:58 | stderr | self.warnings.warn(
2024/07/26 14:49:58 | stderr | /usr/lib/python3/dist-packages/supervisor/options.py:474: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
2024/07/26 14:49:54 | stderr | adduser: The UID 0 is already in use.
2024/07/26 14:49:54 | stderr | addgroup: The GID `0' is already in use.
Screenshot from ls -al in /app/Api
Screenshot from ls -al in /app/Identity
Screenshot from ls -al in /app/Sso
Not sure why but it appears that for me when docker builds the patched image bitwarden-patch from bitwarden/self-host:beta the file permissions are messed up and are set to 000 when they are supposed to be set to 644 (Core.dll of unmodified services have 644 permissions). If I open a terminal in the modified image I can run the following command to fix the permissions:
chmod 644 /app/Api/Core.dll
chmod 644 /app/Identity/Core.dll
Restarting the container then allows all services to start up without issue with PUID and GUID set to non-zero values.
To run those commands when the image is built I modified "src/bitBetter/Dockerfile-bitwarden-patch".
Original:
FROM bitwarden/self-host:beta
COPY ./temp/Api/Core.dll /app/Api/Core.dll
COPY ./temp/Identity/Core.dll /app/Identity/Core.dll
Modified:
FROM bitwarden/self-host:beta
COPY ./temp/Api/Core.dll /app/Api/Core.dll
COPY ./temp/Identity/Core.dll /app/Identity/Core.dll
RUN chmod 644 /app/Api/Core.dll
RUN chmod 644 /app/Identity/Core.dll
The permissions are now forcibly set to 644 after coping the modified Core.dll files into the patched image during the build process. The resulting image now has the correct permissions.
I am using the BitBetter unified branch. After running build.sh and starting bitwarden with the bitwarden-patch image using docker compose, the API and Identity services are entering a fatal state.
Docker container logs:
api.log file:
identity.log file:
If I down the docker compose stack and change the image back to bitwarden/self-host:beta all the services start up just fine.
Docker container logs (unmodified bitwarden/self-host:beta image):
Bitwarden Dashboard (unmodified bitwarden/self-host:beta image):