python manage.py dbshell does not enter password from settings.py

[Kaell <joshalto@…>]

When using "python manage.py dbshell" the password from settings.py is not entered for you.

In order to read the password from settings.py one must have access to settings.py, in which case there is no security reason to not enter the password for the user. If they have read access, it should be entered for them. This is not currently the case.

This issue surely extends to django-admin.py as well as manage.py, though I have not tested this directly.

[Malcolm Tredinnick]

Most of the database shells require the password to be entered at the prompt (i.e. via stdin). You cannot pass it on the command line. Faking out stdin input is unreliable and not particularly portable. So this isn't really possible to do. If you really don't want to have to enter the password each time, there's usually a way to set it up in the .psql or .mysql file in your home directory.

[FunkyBob]

This (untested) patch should let postgres log in without requiring you to type your password. HOWEVER-- the PG docs note it's still a POTENTIAL SECURITY ISSUE

[bradleyayers]

I think the issue FunkyBob raised of the PostgreSQL documentation recommending against using an environment variable to supply the password can be resolved by adding an --insecure command line argument to manage.py dbshell. This would follow the convention established by manage.py runserver.

When a user supplies the --insecure argument, they're giving consent to database backends using insecure techniques to supply the password to the database shell (e.g. using command line argument, or setting an environment variable like PostgreSQL's PGPASSWORD).

Based on this rational I'm re-opening this ticket for re-evaluation.

[Aymeric Augustin]

We've had security reports about the fact that the --insecure option of runserver is, well, insecure. No kidding. So I'm against adding the possibility to do insecure things in Django, no matter how obvious and fat the warnings are.

The ticket was closed as wontfix by Malcolm because the databases provide other, more suitable ways to supply the password. See TicketClosingReasons/DontReopenTickets.

[Anssi Kääriäinen]

For PostgreSQL: We could instruct users to save the password in their .pgpass file. First try with -w (never prompt for password) if that does not succeed add a hint "Can't login without password - try saving connection information to your .pgpass file (see ... for details)". Then try again without -w.

Alternate solution is to create a temporary password file, and make sure it is not word-readable. Then, use the environment variable PGPASSFILE to use the temporary password file. It seems it should be easy to make this work on Linux, but Windows will be a bit harder (see ​http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile)

[FunkyBob]

As requested, the patch now adds a "--insecure" switch to dbshell command so you must choose to permit it.

[Robert Coup]

Since v8.1 Postgres supports the PGPASSFILE environment variable to specify an alternative location for a ~/.pgpass file. So one option is for dbshell to create a tempfile, set the file permissions to 0600, write the password into it, then destroy it after invoking psql.

​https://www.postgresql.org/docs/9.6/static/libpq-pgpass.html

[Tim Graham]

That approach was implemented in #23658.