Bitwarden Unified with MariaDB leads to "SIGABRT (core dumped); not expected" #2718
Comments
l4rm4nd
added
bug
bw-unified-deploy
|
Hi there, Thank you for your report! I was able to reproduce this issue, and have flagged this to our engineering team. If you wish to add any further information/screenshots/recordings etc., please feel free to do so at any time - our engineering team will be happy to review these. Thanks once again! |
|
I had this issue and checked the admin.log file. The bitwarden container wasn't able to talk to my mariadb container. Easily fixed by adding the bitwarden container to the same network as mariadb. |
It's a single compose file and all containers run in the same network. |
Indeed my config was just special and maria wasn't in the default network. Might find something useful in the failed services logs if you're lucky. |
|
Same problem for me. Docker Log: |
|
I was able to reproduce this easily. Looks like OP changed the services: to It will still run, however if you change the container name with the "container_name:" variable. |
Hmm this would be weird. The database container name is referenced in the env file so it should work technically if you rename stuff. |
|
In my case the application was not checking if the |
|
i run also into this, is there a solution? |
|
I dove a bit into this and it seems it's caused by mariadb compatibility somehow. An easy workaround in to use a postgres database and use one of the latest versions of the bitwarden/self-host This should do for anyone still struggling with this issue to get an easy setup working Please note that Postgres docker image used here (latest) has multiple vulnerability, I would not advise running this server and exposing if not in a local network. |
I can confirm that the image works with postgresql. I've a working example here.
Although the postgresql docker image lists publicly known CVEs, this is not a problem. Nearly each docker image has known vulnerabilities, often from an upstream library or local OS dependencies. MariaDB for example has also known CVEs for their latest image (see here). So don't be fooled into believing this is a big issue and you cannot securely expose an application with latest postgresql/mariadb docker image. The maintainers are tracking CVEs thoroughly and will fix relevant vulnerabilities in a timely manner. Some CVEs just do not have priority for fixing, as they (often) cannot be remotely exploited. Therefore, they will stay unfixed and be found by image vuln scanners. But of course, never expose a database server to the Internet. Unnecessary anyhow. |
|
That was a quick draft to highlight the fact that the image works with postgres. Better safe than sorry :) I respect what malicious and talented people can do with very little. And trust me, you should too. I am very much shocked by how lightly you take the subject, and how assertive you sound. I beg to disagree with lots and I personally would simply follow some easy better practices:
It might often not be a big issue, probably, but you cannot deny it is problematic still and it can get pretty ugly in some very very rare cases. P.S. Please update the title to make it clear the issue is linked to mariadb, this could help people link this issue with potential duplicates. |
l4rm4nd
changed the title
|
Sorry, didn't want to come off as rude or assertive.
Just wanted to state that the world is not that dark as you painted it. If you have a look into the publicly known CVEs for postgresql and mariadb, you may see that those are not directly exploitable. Using an alpine image with no referenced CVEs is much better though, true! I do not take such things lightly, as I work professionally in the security field. So likelihood, impact and the resulting risk is important. CVSS scores are most often boosted and do not include relevant factors such as exploitability and environmental factors. This will hopefully be fixed by CVSS 4.0 now.
I am fully on your side here. Sorry if it came off otherwise.
Done. |
Thanks, i did already after i asked here for a solution, i forgot to tell. it worked for me with this: And the Postgres container: and the initial DB creation script "init-db.sql": |
|
Just fine that psql is better. |
|
For me, it works fine on 2024.1.0-beta but fails with 2024.1.1-beta. |
I wonder if the root cause here is actually #3651 ? I arrived at this issue via Google, trying to figure out why 2024.1.1-beta is crashing, but it looks like it's fixed in #3651 |
|
Thanks @quiode and @danepowell Reverting to bitwarden/self-host:2024.1.0-beta from "latest" and running the fix from #3651 : ALTER TABLE Grant DROP COLUMN Id; and ALTER TABLE |
I also had to revert to this image. The latest image was giving NGINX errors before and after running the SQL commands. To be clear, I was getting MARIADB errors mentioned above, as well as an NGINX error in the bitwarden container:
Resolved now as mentioned above. For others needing concise instructions:
ALTER TABLE `Grant` DROP COLUMN `Id`;
ALTER TABLE `Grant` ADD PRIMARY KEY `PK_Grant` (`Key`); |
Steps To Reproduce
docker compose updocker-compose.yml:
setting.env:
Expected Result
The Bitwarden Unified instance should be running and be available on http://127.0.0.1:8888
Actual Result
Screenshots or Videos
Additional Context
No response
Githash Version
502 Bad Gateway
Environment Details
Database Image
image: mariadb:10
Issue-Link
#2480
Issue Tracking Info
The text was updated successfully, but these errors were encountered: