Обсуждение: Suggestion : support for environment variable in initdb to set the superuser password

Поиск
Список
Период
Сортировка
Hi,

The initdb command currently supports prompting for the superuser password using --pwprompt or reading it from a file using --pwfile. I’m wondering if it might also make sense to allow specifying the password via an environment variable.

I do believe it can be useful in a variety of settings, but I'm not sure whether this is secure. Specifically, the documentation advises against using PGPASSWORD for connecting to postgres :

"Use of this environment variable is not recommended for security reasons, as some operating systems allow non-root users to see process environment variables via ps; instead consider using a password file (see Section 32.16)." (32.15. Environment Variables)

In my opinion, the context for using PGPASSWORD (i.e. connecting to an instance) is very different from that of initdb, where the password is only used once during cluster initialization. So I think the security concerns from section 32.16 may not necessarily apply here.

I'm looking to contribute to postgres and I'm pretty sure this would be a good opportunity for getting into the code, but I'm not sure if this idea is relevant and I’d appreciate your thoughts on whether it's worth pursuing.

Best regards,
Reda AGAOUA
On 27.05.25 11:43, Reda Agaoua wrote:
> I do believe it can be useful in a variety of settings, but I'm not sure 
> whether this is secure. Specifically, the documentation advises against 
> using PGPASSWORD for connecting to postgres :
> 
> "Use of this environment variable is not recommended for security 
> reasons, as some operating systems allow non-root users to see process 
> environment variables via ps; instead consider using a password file 
> (see Section 32.16)." (32.15. Environment Variables)
> 
> In my opinion, the context for using PGPASSWORD (i.e. connecting to an 
> instance) is very different from that of initdb, where the password is 
> only used once during cluster initialization. So I think the security 
> concerns from section 32.16 may not necessarily apply here.

Well, insecure is insecure.  "Insecure, but it's ok because it's not 
used very often" is not a valid excuse.




Le mer. 28 mai 2025, 13:26, Peter Eisentraut <peter@eisentraut.org> a écrit :
On 27.05.25 11:43, Reda Agaoua wrote:
"Insecure, but it's ok because it's not
used very often"

This isn't what I meant, but I guess it's the same so maybe I didn't think this through as much as I thought I had !

Still, is the concern relevant for single-user systems ? Like containers for instance ? Plus, should we really discourage the use of environment variables altogether just because *some* systems allow unprivileged users to access others processes environment variables ? I'm really curious about this.

Thanks for your consideration anyway !
Reda Agaoua

(Sorry for responding twice, forgot the hit "reply all")