Code Monkey home page Code Monkey logo

Comments (4)

BlackDex avatar BlackDex commented on June 29, 2024 1

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.

from vaultwarden.

BlackDex avatar BlackDex commented on June 29, 2024

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.

from vaultwarden.

pimlie avatar pimlie commented on June 29, 2024

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

from vaultwarden.

tessus avatar tessus commented on June 29, 2024

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.

from vaultwarden.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.