Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add command line option to read password from a file #278

Closed
MirkoDziadzka opened this issue Aug 25, 2015 · 15 comments

Comments

Projects
None yet
8 participants
@MirkoDziadzka
Copy link
Contributor

commented Aug 25, 2015

would be great if rustic could read the encryption password from a file instead of the environment

@fd0

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

Thanks for the suggestion. What's your use case? Did you know that you can use the environment variable RESTIC_PASSWORD to tell it the password?

Btw: It's called "restic", not "rustic".

@MirkoDziadzka

This comment has been minimized.

Copy link
Contributor Author

commented Aug 25, 2015

Sorry for the typo in the name, it was not intended.

Environment variables may be shown in the ps outputs and sometimes the ps output of a system tends to be written to log files for diagnostic reasons of unrelated stuff. Which is not a good place for a password to end up.

@fd0

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

Hm. Logging the environment of current processes may be a reason to add this function.

@fw42 what do you think?

@fw42

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

Yeah he's right, I think environment variables are a bad place to store passwords. We should discourage that (possibly completely remove that feature).

@episource

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

Passing the password using an environment variable is nice for scripting. While a more secure alternative is always good, support for the environment variable RESTIC_PASSWORD shouldn't be dropped needlessly. Finally it's fine according to the threat model:

General assumptions:
The host system a backup is created on is trusted. This is the most basic requirement, and essential
for creating trustworthy backups.
(https://github.com/restic/restic/blob/master/doc/Design.md#threat-model)

@fw42

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

it's okay-ish when used like this:

export RESTIC_PASSWORD=foo
restic ...

but not when used like this:

RESTIC_PASSWORD=foo restic ...

if there is no way to allow one but not the other then I would say to remove it completely, but ymmv

@rawtaz

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2015

I'd say keep the environment variable way too. It can be useful for quick tests and what not.

I think people should be able to know what each of these two things do and make an educated decision. We cannot make the entire restic built to suit only people that have no clue what they're doing. If the documentation clearly points to using a file for permanent storing of the password then most people would go with that. I don't think this is a problem.

@fd0

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

it's okay-ish when used like this:

export RESTIC_PASSWORD=foo
restic ...

but not when used like this:

RESTIC_PASSWORD=foo restic ...

if there is no way to allow one but not the other then I would say to remove it completely, but ymmv

Both use cases are the same regarding restic: The password will end up in that proc's environment and ps e will list it. export is a shell keyword, signalling the shell that this variable should be passed on to newly spawned processes.

I'm a bit torn here: On the one hand, ps can only read the environment (via /proc/PID/environ) for processes running as the same user (or ps is called as root), so ps has the same "trust level" as the restic process itself. That's what the section in the threat model is about. After all, instead of calling ps someone could also just send SIGSEGV to the running restic process to dump the memory and extract the password (or even the raw encryption keys) from that.

On the other hand I think systems that regularly log all processes together with the environment are a pretty special case, that's not a common thing I've come across so far. Therefore we could add the possibility to read the password from the file. Or disregard this use case as too obscure.

At the moment I'm in favor of adding an option to read from a file (especially since it's really not much added code), but I still consider storing the password in an environment variable secure in most usual environments.

We should definitely add a section in the user manual about storing the password when the backup is run by a script.

Agree @fw42?

@fw42

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

Both use cases are the same

you are right, I didn't get that... In that case I think neither should work :-)

But if you think documenting the possible dangers of this is good enough then sure, no big deal.

@fd0

This comment has been minimized.

Copy link
Member

commented Aug 25, 2015

Great, then we have a plan. :)

@fd0 fd0 removed the rfc label Aug 25, 2015

@eripa

This comment has been minimized.

Copy link

commented Sep 22, 2015

Just FYI, one could also put the password in a file by using shell expansion, some like this:

echo 'superSecretPassw0rd' > restic_password
chmod 0400 restic_password
RESTIC_PASSWORD=$(cat restic_password) restic -r repository_path snapshots
@MirkoDziadzka

This comment has been minimized.

Copy link
Contributor Author

commented Sep 22, 2015

Yeah, but this would it also part of the environment of the restic process. Which is my original problem with the environment variable approach.

@fd0

This comment has been minimized.

Copy link
Member

commented Nov 4, 2015

Another thing might be password managers like the apple keychain and the likes, maybe they need to execute a command? What do you think about having an option to read the password from a file and another one reading from a command?

This is also interesting: https://security.stackexchange.com/questions/14000/environment-variable-accessibility-in-linux/14009#14009

@jannic

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2016

If you can read the password from a file, an allow for special files like /dev/fd/..., you could use the bash feature "Process Substitution" to read the password from a command's output:
restic --password-file <(password-generating-command) ....

@juergenhoetzel

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2016

would be great if restic could read the encryption password from a file instead of the environment

restic can already read passwords from stdin
I just use this shell script. Instead of a HEREDOC you could also redirection from a file:

#!/bin/bash
export RESTIC_REPOSITORY=/mnt/restic
restic backup ~/<<EOF
mypassword
EOF

So i don't have a need for a read-password-from-file feature: Did I miss something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.