hi all!
sorry if you are recieving this 3 times, i am too stupid to file a simple
bugreport (4rd!!! try already) . btw the bugreport webinterface is
broken.
i am using version 7.4.7/Debian of postgres.
as far as i understand the standard, the following situation should not
be possible. neither i
I know this is not a bug, but I didn't see a list that I thought this
would fit into.
I saw in the documentation that PGPASSWORD is deprecated in favor of of
the .pgpass file for security reasons.
I would like to recommend removing the deprecation flag from PGPASSWORD.
It is very useful in dyn
Klaus Ita wrote:
i have the following data:
table L:
LNR ORT LCODE MENGE
L1 GrazA 1000
L2 WienC 500
L3 WienC 1500
L4 LinzB 1000
L5 GrazB 300
table P:
PNR PNAME ORT PREIS
P1 Alpha Wien50.00
P2
Hi Richard!
burn me, damn me! thank you. it is now working and i will sit back and
read some more of the conf-options.
you just gave me a huge argument for the db and so i will probably win
my fight against a stubborn professor, that wants to stick to his big
fat oe 'cause it is the most conf
Klaus Ita wrote:
Hi Richard!
burn me, damn me! thank you. it is now working and i will sit back and
read some more of the conf-options.
It catches lots of people out. Helpful sometimes, but mostly I spend
time puzzling just like you did.
you just gave me a huge argument for the db and so i will p
postgresbugs <[EMAIL PROTECTED]> writes:
> I would like to recommend removing the deprecation flag from PGPASSWORD.
Do you understand why it's deprecated? It's because on some operating
systems, everyone on the machine can see your environment variable
values (if they know how to look). We cann
Tom Lane wrote:
postgresbugs <[EMAIL PROTECTED]> writes:
I would like to recommend removing the deprecation flag from PGPASSWORD.
Do you understand why it's deprecated? It's because on some operating
systems, everyone on the machine can see your environment variable
values (if they know how to l
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Assuming that you can't tweak .pgpass (for example, you're just
> propagating a password you interactively got from the user), what's the
> recommended way to provide the password?
In the connection string given to PQconnectdb (or equivalent).
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Assuming that you can't tweak .pgpass (for example, you're just
propagating a password you interactively got from the user), what's the
recommended way to provide the password?
In the connection string given to PQconnectdb (or equivalent)
Oliver Jowett <[EMAIL PROTECTED]> writes:
> If you're a shell script calling psql / pg_dump / etc, how do you do this?
That doesn't strike me as a compelling case for inventing "--password-fd".
Such a shell script is going to have a hard time passing a password
securely anyway (you weren't plannin
Oliver Jowett wrote:
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Assuming that you can't tweak .pgpass (for example, you're just
propagating a password you interactively got from the user), what's
the recommended way to provide the password?
In the connection string given to PQconn
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
If you're a shell script calling psql / pg_dump / etc, how do you do this?
That doesn't strike me as a compelling case for inventing "--password-fd".
Such a shell script is going to have a hard time passing a password
securely anyway (you w
postgresbugs <[EMAIL PROTECTED]> writes:
> Unless the utilities like psql and pg_dump are changed to accept a
> password as a command line option, I don't think PGPASSWORD should go
> away. It is too useful for those that know how to properly use and
> destroy environmental variables.
... which
Oliver Jowett <[EMAIL PROTECTED]> writes:
> My main objections to using .pgpass are:
> - the script/application itself has no business meddling with .pgpass
It isn't. The password sits in .pgpass and is never touched by the
script. Really the script doesn't know it is there. (For that matter,
Tom Lane wrote:
- the user might not want to store their password in .pgpass
Without a concrete argument why they should not, this is a straw man.
I think this is the core of our disagreement.
Storing passwords on the client's disk is surely less secure than not
storing them on disk. That's my per
Tom Lane wrote:
postgresbugs <[EMAIL PROTECTED]> writes:
Unless the utilities like psql and pg_dump are changed to accept a
password as a command line option, I don't think PGPASSWORD should go
away. It is too useful for those that know how to properly use and
destroy environm
Tom Lane wrote:
Agreed, which is why we invented .pgpass. But that argument scales up
to beyond one invocation of this hypothetical script, does it not?
regards, tom lane
I guarantee you that his process which includes binaries and scripts is
not hypothetical.
Regards,
John Griffiths
postgresbugs wrote:
Tom Lane wrote:
The point here is that if
PGPASSWORD is passed down to psql as an environmental variable, it is
visible as part of psql's environment for the entire run of psql.
Whatever the calling script does later doesn't remove that window of
vulnerability.
[...]
And, yes I
postgresbugs wrote:
Tom Lane wrote:
Agreed, which is why we invented .pgpass. But that argument scales up
to beyond one invocation of this hypothetical script, does it not?
regards, tom lane
I guarantee you that his process which includes binaries and scripts is
not hypothetical.
Oliver Jowett wrote:
postgresbugs wrote:
Tom Lane wrote:
The point here is that if
PGPASSWORD is passed down to psql as an environmental variable, it is
visible as part of psql's environment for the entire run of psql.
Whatever the calling script does later doesn't remove that window of
vulnerabi
20 matches
Mail list logo
