initdb initial password
I would like to add capability to initdb to accept the password for the
superuser account at invocation. Right now, I can use --pwprompt or -W
to have it ask for a password. But for the win32 GUI installed I'd like
to ask for the password in the installer, and pass it to initdb.
Considering how it's done in different places, what's the preferred way
to do this? Commandline parameter? Environment variable? Other (what
would that be?)
//Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
I would like to add capability to initdb to accept the password for the
superuser account at invocation. Right now, I can use --pwprompt or -W
to have it ask for a password. But for the win32 GUI installed I'd like
to ask for the password in the installer, and pass it to initdb.
Considering how it's done in different places, what's the preferred way
to do this? Commandline parameter? Environment variable? Other (what
would that be?)
There's a reason why it's done that way, which is that the others are
all insecure. At least on some Unixen.
regards, tom lane
I would like to add capability to initdb to accept the
password for the
superuser account at invocation. Right now, I can use
--pwprompt or -W
to have it ask for a password. But for the win32 GUI
installed I'd like
to ask for the password in the installer, and pass it to initdb.
Considering how it's done in different places, what's thepreferred way
to do this? Commandline parameter? Environment variable? Other (what
would that be?)There's a reason why it's done that way, which is that the others are
all insecure. At least on some Unixen.
Other binaries accept the password as an environment variable. Are you
saying that it's secure to pass it as environment variable to
psql/pgdump/etc but not to initdb? If so, care to enlighten me as to why
this is different (I'm clearly not seeing why..)?
Assuming it isn't, would a patch that added a commandline switch for
this on win32 only (#ifdef:ed) be accepted? On win32 you can't see the
commandline of another process (unless you are admin on the box and
activate debugging privileges, but you've lost against an admin anyway -
same as root on *nix), so it should be safe enough there.
//Magnus
Import Notes
Resolved by subject fallback
Tom Lane said:
"Magnus Hagander" <mha@sollentuna.net> writes:
I would like to add capability to initdb to accept the password for
the superuser account at invocation. Right now, I can use --pwprompt
or -W to have it ask for a password. But for the win32 GUI installed
I'd like to ask for the password in the installer, and pass it to
initdb. Considering how it's done in different places, what's the
preferred way to do this? Commandline parameter? Environment variable?
Other (what would that be?)There's a reason why it's done that way, which is that the others are
all insecure. At least on some Unixen.
I think a parameter to have initdb read the password from a file ought to
be safe enough. Mark it as one of the less used options - it's really only
of significant benefit for installers, I should think.
cheers
andrew
"Magnus Hagander" <mha@sollentuna.net> writes:
I would like to add capability to initdb to accept the
password for the
superuser account at invocation. Right now, I can use
--pwprompt or -W
to have it ask for a password. But for the win32 GUI
installed I'd like
to ask for the password in the installer, and pass it to initdb.
Considering how it's done in different places, what's thepreferred way
to do this? Commandline parameter? Environment variable? Other (what
would that be?)There's a reason why it's done that way, which is that the others are
all insecure. At least on some Unixen.Other binaries accept the password as an environment variable. Are you
saying that it's secure to pass it as environment variable to
psql/pgdump/etc but not to initdb? If so, care to enlighten me as to why
this is different (I'm clearly not seeing why..)?
The environment variable is there for backward compatibility, but it's
deprecated. There's no reason to enable that functionality in new
code.
-Doug