Newly created configuration files are world readable

[pimlie]

Subject of the issue

After setting up a new (docker) instance of vaultwarden, all configuration files/folders have 644/755 permissions

Deployment environment

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.30.5
• Web-vault version: v2024.1.2b
• OS/Arch: linux/x86_64
• Running within a container: true (Base: Debian)
• Environment settings overridden: true
• Uses a reverse proxy: true
• IP Header check: true (X-Real-IP)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• Domain Configuration Check: true
• HTTPS Check: true
• Database type: SQLite
• Database version: 3.44.0
• Clients used:
• Reverse proxy and version:
• Other relevant information:

Steps to reproduce

Start a new vaultwarden docker instance and mount the /data volume to a new folder

Expected behaviour

Vaultwarden configuration files should not be world readable, maybe even don't let groups have (write) access by default. So all files under /data should have at least 660/770 permissions and maybe 640/750 or 600/700

Actual behaviour

Vaultwarden configuration files are world readable

Troubleshooting data

/data$ ls -laF
total 308
drwxr-xr-x 6 root root   4096 May 18 13:48 ./
drwxr-xr-x 1 root root   4096 May 18 13:48 ../
drwxr-xr-x 2 root root   4096 May 18 13:48 attachments/
-rw-r--r-- 1 root root 249856 May 18 13:48 db.sqlite3
-rw-r--r-- 1 root root  32768 May 18 13:48 db.sqlite3-shm
-rw-r--r-- 1 root root      0 May 18 13:48 db.sqlite3-wal
drwxr-xr-x 2 root root   4096 May 18 13:48 icon_cache/
-rw-r--r-- 1 root root   1675 May 18 13:48 rsa_key.pem
-rw-r--r-- 1 root root    451 May 18 13:48 rsa_key.pub.pem
drwxr-xr-x 2 root root   4096 May 18 13:48 sends/
drwxr-xr-x 2 root root   4096 May 18 13:48 tmp/

[BlackDex]

There is no sane default you can configure here. Some users are relying on the world readable to be able to backup for example.
Setting it to 660/770 or 640/750 could also be causing issues, but probably less.

Also, there unfortunately is no quick and easy solution to solve this exxcept by always setting the modes during all write actions.
That might cause some overhead. And also, there is no general umask functionality in Rust which respect these settings.

We might be able to centralize all file writing actions maybe and allow something like a umask behavior. Only file uploads need to be handled differently since those are done by Tempfile.

Though, the default then still would first be 644/755 i think to not break existing installations.

[pimlie]

There is no sane default you can configure here

It is often best to be secure-by-default, and allow users to be less secure if they have a need for that like with your backup example (even though they should configure that through the group and add their backup user to the vw group). Especially for a product like a password manager, the sane default should be as strict as what is at minimum needed for vw to run.

there unfortunately is no quick and easy solution to solve

Aren't there something like a pre-start or post-release-upgrade hooks?
For existing installations, I don't think this is something that needs to be checked on every write, should be fine just on startup and/or after an upgrade.
For new installations, it sounds like you are saying that configuration files are created implicitly instead of explicitly? Isn't it possible to detect if a file exists and if not create it & set umask after creating it instead of f.e. doing all at once?

the default then still would first be 644/755 i think to not break existing installations

It would probably be best to come up with a migration path that would allow us to fix this behaviour without breaking user space indeed. Cause the rsa_key is world readable too, which is pretty unsafe. Also compare this to ssh behaviour, if your ssh keys are world readable then as a security consideration you often can't even use them at all.

F.e. a migration path could look something like this:

• on startup, check if user has specifically configured the user permissions (this should be a vw setting, so don't check the file system permissions themselves for this)
• if user defined permissions, ensure configuration files are using these user defined permissions and either fix & log a warning when permissions are different or just error-out and let the user fix the permissions (as it might be better to be explicit so the user can fe investigate why the permissions have changed)
• if user did not define permissions, check if this is a new or an existing installation
• if existing installation, don't try to change the user permissions but log a warning about possible unsafe permissions
• if new installation, enforce the most secure file permissions when creating all files

For docker, it would probably be best to just always run the vw server as a user instead of root, but let the user specify UID & GID through environmental variables. In docker it should then also be safe to change the default UMASK for that user to 027

[BlackDex]

A quick reply regarding the docker user, that isn't something easily changed, as that also breaks existing setups. If something like that is to be done it needs to be announced upfront for a long time.
There might be some way to have root still as a default and be adjustable. But the migration is very error prone.

I do agree that the current way isn't ideal, but changing it also is not that easy with all the different setups already running.

[tessus]

I "fixed" the issue on my side by setting the permissions of the /etc/vaultwarden and /data directories to 750 and using a separate vaultwarden uaer and group.

I'm using vaultwarden w/o docker and with MySQL, but your data dir is a bind mount, so you can always change the dir permissions easily.