Attachments don't obey UMASK environment variable #1809

New Issue

OVERLORD · 2026-02-05T01:52:08+03:00

OVERLORD commented

2026-02-05 01:52:08 +03:00

Originally created by @JHthe4 on GitHub (Dec 21, 2023).

Not sure if this is intended behavior or a bug - if it's the former, please close the issue.

The UMASK environment variable was mentioned in #2610 , but it seems that it doesn't apply to attachments, which makes them impossible to back up with non-root permissions, even though they're encrypted. It seems like the TempFile.persist_to() call doesn't have any way to set file permissions itself, so a chmod after persisting would be necessary somehow. I'm not familiar with Rust or Rocket, but it seems like this would be a possible, non-breaking change. I've attached the discussion below for convience that outlines my reasoning for this report. It doesn't really seem like there are other solutions in the community, so I do think this is an important fix to enable rootless backup.

Discussed in https://github.com/dani-garcia/vaultwarden/discussions/4166

^{Originally posted by JHthe4 December 14, 2023}
Hi everyone,

I'm trying to automate a nightly backup of my vaultwarden instance using a normal user account and I'm trying to avoid any commands which require root privileges. The container is run as root, and the data folder is owned by root. Reading the sqlite file is no problem, but the attachment files have permissions rw-------, so the user can't read them.

I'm wondering what the best practice for solving this problem is. How can I configure world read permissions for the attachments folder without changing the ownership of all files or running the container as a different user? I want to avoid giving any user write permissions on the data folder.

As reported here in #2610 , the UMASK=022 environment variable doesn't work for me either.

Thanks!

Originally created by @JHthe4 on GitHub (Dec 21, 2023). Not sure if this is intended behavior or a bug - if it's the former, please close the issue. The UMASK environment variable was mentioned in #2610 , but it seems that it doesn't apply to attachments, which makes them impossible to back up with non-root permissions, even though they're encrypted. It seems like the TempFile.persist_to() call doesn't have any way to set file permissions itself, so a chmod after persisting would be necessary somehow. I'm not familiar with Rust or Rocket, but it seems like this would be a possible, non-breaking change. I've attached the discussion below for convience that outlines my reasoning for this report. It doesn't really seem like there are other solutions in the community, so I do think this is an important fix to enable rootless backup. ### Discussed in https://github.com/dani-garcia/vaultwarden/discussions/4166 <div type='discussions-op-text'> <sup>Originally posted by **JHthe4** December 14, 2023</sup> Hi everyone, I'm trying to automate a nightly backup of my vaultwarden instance using a normal user account and I'm trying to avoid any commands which require root privileges. The container is run as root, and the data folder is owned by root. Reading the sqlite file is no problem, but the attachment files have permissions rw-------, so the user can't read them. I'm wondering what the best practice for solving this problem is. How can I configure world read permissions for the attachments folder without changing the ownership of all files or running the container as a different user? I want to avoid giving any user write permissions on the data folder. As reported here in #2610 , the UMASK=022 environment variable doesn't work for me either. Thanks!</div>

OVERLORD closed this issue

2026-02-05 01:52:11 +03:00

OVERLORD referenced this issue

2026-02-05 05:06:23 +03:00

[PR #1809] [MERGED] Fix armv7 alpine build. #2980

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1809