subprocess pipe

[Camille Harang]

Hi all,

I'm having a problem with subprocess.Popen. It seems that its unable to
capture the pg_dump's standard inputs & outputs in a non-shell mode:

from subprocess import Popen, PIPE

# fire pg_dump in order to read data from the file object pgsql.stdout
pgsql = Popen(['/usr/bin/pg_dump',
'--host', 'localhost',
'--password',
'--username',
'mammique'],
stdin=PIPE,
stderr=PIPE,
stdout=PIPE,
shell=True)

# pg_dump prompts for password so I inject it in stdin.
pgsql.stdin.write('MY_PASSWORD' + '\n')

In the shell mode (shell=True) pipes works but the args (username, etc.)
are omitted. If I turn to shell=False the arguments are passed to
pg_dump but subprocess.Popen is no longer able to capture the standard
inputs & outputs, the password prompt appears on the TTY instead and
doesn't take the input written in stdin. It seems that subprocess.Popen
has only this problem with pg_dump, other interactive command lines
seems to be correctly handled.

Any lead?

Thanks,

Camille.

 

[Tim Harig]

# pg_dump prompts for password so I inject it in stdin.
pgsql.stdin.write('MY_PASSWORD' + '\n')

For security reasons, some programs use direct access to the TTY system
for password entry rather then reading from stdin. Most of these programs
provide another access mechanism that can be used for authentication
(ie public keys or storing the password in a permission restricted
configuration file.

 

[Tim Harig]

# pg_dump prompts for password so I inject it in stdin.
pgsql.stdin.write('MY_PASSWORD' + '\n')

For security reasons, some programs use direct access to the TTY system
for password entry rather then reading from stdin. Most of these programs
provide another access mechanism that can be used for authentication
(ie public keys or storing the password in a permission restricted
configuration file.[) for scripts.

..pgpass ?

 

[Camille Harang]

Tim Harig a écrit :

For security reasons, some programs use direct access to the TTY system
for password entry rather then reading from stdin. Most of these programs
provide another access mechanism that can be used for authentication
(ie public keys or storing the password in a permission restricted
configuration file.

Ha, indeed, I suspected that pg_dump didn't behave normally, security
matters might be an explanation, I'll dig in that way, thanks a lot.

Regards,

Camille.

 

[Camille Harang]

Tim Harig a écrit :

For security reasons, some programs use direct access to the TTY system
for password entry rather then reading from stdin. Most of these programs
provide another access mechanism that can be used for authentication
(ie public keys or storing the password in a permission restricted
configuration file.

Ha, indeed, I suspected that pg_dump didn't behave normally, security
matters might be an explanation, I'll dig in that way, thanks a lot.

Regards,

Camille.

 

[Camille Harang]

Tim Harig a écrit :

For security reasons, some programs use direct access to the TTY system
for password entry rather then reading from stdin. Most of these programs
provide another access mechanism that can be used for authentication
(ie public keys or storing the password in a permission restricted
configuration file.

Ha, indeed, I suspected that pg_dump didn't behave normally, security
matters might be an explanation, I'll dig in that way, thanks a lot.

Regards,

Camille.

 

[Nobody]

For security reasons, some programs use direct access to the TTY system
for password entry rather then reading from stdin.

Indeed, the getpass() function exists[1] for this purpose:

The getpass() function opens /dev/tty (the controlling terminal of the
process), outputs the string prompt, turns off echoing, reads one line
(the "password"), restores the terminal state and closes /dev/tty
again.

[1] Or existed. It was dropped from the Unix standard in POSIX.1-2001, but
most systems still provide it.