github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-03-16 03:40:42 -05:00
Code Issues 79 Packages Projects Releases 78 Wiki Activity

permissions of files in attachments/sends are 600 not 644 #1319

New Issue
Closed
opened 2025-11-07 07:03:35 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-07 07:03:35 -06:00
Owner
Copy Link

Originally created by @hellodword on GitHub (Jul 9, 2022).

Subject of the issue

rocket::fs::TempFile::persist_to() will create file as 600, will have backup issue when using some cloud storage.

Deployment environment

  • vaultwarden version: 1.25.0

  • Install method: docker run --rm --name bitwarden -e WEB_VAULT_ENABLED=false -e WEBSOCKET_ENABLED=false -p 8888:80 -v $(pwd)/data:/data vaultwarden/server:1.25.0

  • Clients used: all

  • Reverse proxy and version: none

  • MySQL/MariaDB or PostgreSQL version: none

Steps to reproduce

Create a send, or an attachment.

ls -R -l /data/attachments/

ls -R -l /data/sends/

# /data/attachments/dec756ad-1481-4e2b-9b9d-9a74ba5d3eb9:
# -rw-------+ 1 root root 65 Jul  9 14:01 794d8b149b9a0f39dcc6

b64cf27038/src/api/core/ciphers.rs (L1001)
b64cf27038/src/api/core/sends.rs (L228)

For example, I'm using CFS - kine of cloud storage, I mounted it to vaultwarden as the /data. When I mounted it to another service with a non-root user, I will fail to read the files in /data/attachments and /data/sends.

I think 644 like other files in the /data will bring better compatibility.

Originally created by @hellodword on GitHub (Jul 9, 2022). ### Subject of the issue `rocket::fs::TempFile::persist_to()` will create file as `600`, will have backup issue when using some cloud storage. ### Deployment environment * vaultwarden version: `1.25.0` * Install method: `docker run --rm --name bitwarden -e WEB_VAULT_ENABLED=false -e WEBSOCKET_ENABLED=false -p 8888:80 -v $(pwd)/data:/data vaultwarden/server:1.25.0` * Clients used: `all` * Reverse proxy and version: `none` * MySQL/MariaDB or PostgreSQL version: `none` ### Steps to reproduce Create a send, or an attachment. ```sh ls -R -l /data/attachments/ ls -R -l /data/sends/ # /data/attachments/dec756ad-1481-4e2b-9b9d-9a74ba5d3eb9: # -rw-------+ 1 root root 65 Jul 9 14:01 794d8b149b9a0f39dcc6 ``` https://github.com/dani-garcia/vaultwarden/blob/b64cf27038f04368af8f25aa80782d37471e6303/src/api/core/ciphers.rs#L1001 https://github.com/dani-garcia/vaultwarden/blob/b64cf27038f04368af8f25aa80782d37471e6303/src/api/core/sends.rs#L228 For example, I'm using [CFS - kine of cloud storage](https://intl.cloud.tencent.com/products/cfs), I mounted it to vaultwarden as the `/data`. When I mounted it to another service with a non-root user, I will fail to read the files in `/data/attachments` and `/data/sends`. I think `644` like other files in the `/data` will bring better compatibility.
GiteaMirror commented 2025-11-07 07:03:36 -06:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (Jul 15, 2022):

Well, that is the most safe way actually.
There are even people requesting this (600) as a default for all files.

I would suggest to try and use UMASK=022 as an environment variable and see if that solves your issue.

@BlackDex commented on GitHub (Jul 15, 2022): Well, that is the most safe way actually. There are even people requesting this (600) as a default for all files. I would suggest to try and use `UMASK=022` as an environment variable and see if that solves your issue.
GiteaMirror commented 2025-11-07 07:03:36 -06:00
Author
Owner
Copy Link

@hellodword commented on GitHub (Jul 17, 2022):

@BlackDex Thanks.

Well, that is the most safe way actually.

Isn't the basic security of vaultwarden ensured by it's zero-knowledge? Why people think it's more safer with the file permission in the server-side.?

There are even people requesting this (600) as a default for all files.

I think these two lines are not intentional for security. They're more of coincidence of the dependency rocket::fs::TempFile::persist_to().

@hellodword commented on GitHub (Jul 17, 2022): @BlackDex Thanks. > Well, that is the most safe way actually. Isn't the basic security of vaultwarden ensured by it's zero-knowledge? Why people think it's more safer with the file permission in the server-side.? > There are even people requesting this (600) as a default for all files. I think these two lines are not intentional for security. They're more of coincidence of the dependency `rocket::fs::TempFile::persist_to()`.
GiteaMirror commented 2025-11-07 07:03:36 -06:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (Jul 17, 2022):

@BlackDex Thanks.

Well, that is the most safe way actually.

Isn't the basic security of vaultwarden ensured by it's zero-knowledge? Why people think it's more safer with the file permission in the server-side.?

Well uploaded files you probably do not want to be 755 or something.
That is why most of the time these uploaded files are 600 by default, which is the safe way for Unix based filesystems.

There are even people requesting this (600) as a default for all files.

I think these two lines are not intentional for security. They're more of coincidence of the dependency rocket::fs::TempFile::persist_to().

It isn't Rocket it self, it's the tempfile crate used by Rocket. And as i mentioned before, for uploaded/temp files it's most of the time safer to not have executable rights.

Now, for Vaultwarden this isn't that big of an issue since all uploads are encrypted.

But, I'm a bit hesitant in using fixed rights on all files either 664 or 600, or configurable, for one it will add a performance impact, and it is probably always the wrong default for a lot of people.
The same btw for which user it is running on.

I haven't tried it my self yet, but the UMASK should work, unless the tempfile crate overrides that.

Also, i see you use ACL's. Maybe setting some other acl's on it can also fix this, or settings a sticky bit to force some rights.

@BlackDex commented on GitHub (Jul 17, 2022): > @BlackDex Thanks. > > > Well, that is the most safe way actually. > > Isn't the basic security of vaultwarden ensured by it's zero-knowledge? Why people think it's more safer with the file permission in the server-side.? > Well uploaded files you probably do not want to be 755 or something. That is why most of the time these uploaded files are 600 by default, which is the safe way for Unix based filesystems. > > There are even people requesting this (600) as a default for all files. > > I think these two lines are not intentional for security. They're more of coincidence of the dependency `rocket::fs::TempFile::persist_to()`. It isn't Rocket it self, it's the tempfile crate used by Rocket. And as i mentioned before, for uploaded/temp files it's most of the time safer to not have executable rights. Now, for Vaultwarden this isn't that big of an issue since all uploads are encrypted. But, I'm a bit hesitant in using fixed rights on all files either 664 or 600, or configurable, for one it will add a performance impact, and it is probably always the wrong default for a lot of people. The same btw for which user it is running on. I haven't tried it my self yet, but the `UMASK` should work, unless the `tempfile` crate overrides that. Also, i see you use ACL's. Maybe setting some other acl's on it can also fix this, or settings a sticky bit to force some rights.
GiteaMirror commented 2025-11-07 07:03:36 -06:00
Author
Owner
Copy Link

@hellodword commented on GitHub (Jul 17, 2022):

@BlackDex Thanks.

Well, that is the most safe way actually.

Isn't the basic security of vaultwarden ensured by it's zero-knowledge? Why people think it's more safer with the file permission in the server-side.?

Well uploaded files you probably do not want to be 755 or something. That is why most of the time these uploaded files are 600 by default, which is the safe way for Unix based filesystems.

There are even people requesting this (600) as a default for all files.

I think these two lines are not intentional for security. They're more of coincidence of the dependency rocket::fs::TempFile::persist_to().

It isn't Rocket it self, it's the tempfile crate used by Rocket. And as i mentioned before, for uploaded/temp files it's most of the time safer to not have executable rights.

Now, for Vaultwarden this isn't that big of an issue since all uploads are encrypted.

But, I'm a bit hesitant in using fixed rights on all files either 664 or 600, or configurable, for one it will add a performance impact, and it is probably always the wrong default for a lot of people. The same btw for which user it is running on.

I haven't tried it my self yet, but the UMASK should work, unless the tempfile crate overrides that.

Also, i see you use ACL's. Maybe setting some other acl's on it can also fix this, or settings a sticky bit to force some rights.

Perfect explanation of this issue, got it.

Thanks again @BlackDex !

@hellodword commented on GitHub (Jul 17, 2022): > > @BlackDex Thanks. > > > Well, that is the most safe way actually. > > > > > > Isn't the basic security of vaultwarden ensured by it's zero-knowledge? Why people think it's more safer with the file permission in the server-side.? > > Well uploaded files you probably do not want to be 755 or something. That is why most of the time these uploaded files are 600 by default, which is the safe way for Unix based filesystems. > > > > There are even people requesting this (600) as a default for all files. > > > > > > I think these two lines are not intentional for security. They're more of coincidence of the dependency `rocket::fs::TempFile::persist_to()`. > > It isn't Rocket it self, it's the tempfile crate used by Rocket. And as i mentioned before, for uploaded/temp files it's most of the time safer to not have executable rights. > > Now, for Vaultwarden this isn't that big of an issue since all uploads are encrypted. > > But, I'm a bit hesitant in using fixed rights on all files either 664 or 600, or configurable, for one it will add a performance impact, and it is probably always the wrong default for a lot of people. The same btw for which user it is running on. > > I haven't tried it my self yet, but the `UMASK` should work, unless the `tempfile` crate overrides that. > > Also, i see you use ACL's. Maybe setting some other acl's on it can also fix this, or settings a sticky bit to force some rights. Perfect explanation of this issue, got it. Thanks again @BlackDex !
GiteaMirror commented 2025-11-07 07:03:36 -06:00
Author
Owner
Copy Link

@ChillDuder commented on GitHub (Dec 28, 2022):

Hello,

since - at least - for me umask don't had any effect (regardless if with -e, or in mapped /etc/vaultwarden.sh):

a workaround just for other users, which where also are on research how to backup attachment etc. folder, without using root scripts/systemd timers/whatever root stuff on host to get access on encrypted attachment files.

run chmod like this for those folders inside the container, before making backup:
docker exec vaultwarden chmod -R go+r data/attachments/.; chmod -R go+r data/sends/.
Hopefully this don't fuck up any other stuff in vaultwarden.
Alternative can also be chgrp those files/folder to something usable outside the container. But i think, this can maybe have more impact on vaultwarden processes.

Thank all devs you for that great slim server alternative for bitwarden!

@ChillDuder commented on GitHub (Dec 28, 2022): Hello, since - at least - for me umask don't had any effect (regardless if with -e, or in mapped /etc/vaultwarden.sh): a workaround just for other users, which where also are on research how to backup attachment etc. folder, without using root scripts/systemd timers/whatever root stuff on host to get access on encrypted attachment files. run chmod like this for those folders inside the container, before making backup: docker exec vaultwarden chmod -R go+r data/attachments/.; chmod -R go+r data/sends/. Hopefully this don't fuck up any other stuff in vaultwarden. Alternative can also be chgrp those files/folder to something usable outside the container. But i think, this can maybe have more impact on vaultwarden processes. Thank all devs you for that great slim server alternative for bitwarden!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#1319
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?