Thread: 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 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.

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

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 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.
>
> 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