| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> |
| Cc: | "Sergio A(dot) Kessler" <ser(at)perio(dot)unlp(dot)edu(dot)ar>, "pgsql-interfaces(at)postgreSQL(dot)org" <pgsql-interfaces(at)postgreSQL(dot)org> |
| Subject: | Re: [INTERFACES] pg_pwd |
| Date: | 1999-11-20 22:57:58 |
| Message-ID: | 28767.943138678@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> And yes, this IS a glaring security hole, IF the user postgres has a postgres
> password. Just WHY is pg_pwd mode 666 in the first place??
Because it's written out with a backend-side COPY operation, and
backend-side COPY makes *every* file it creates mode 666.
As I commented earlier in this thread, I think COPY ought not create
files with looser permissions than 644 (does anyone know why that's
not true already?). But that still wouldn't be good enough for pg_pwd.
Maybe it would be worthwhile to try to force pg_pwd in particular
to be written with just mode 600. In the standard configuration that
shouldn't make any difference ... but if people are going to use
hacked-up initdb code, as you evidently are doing, we probably should
not rely on the data directory to be locked up tightly...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lamar Owen | 1999-11-20 23:29:44 | Re: [INTERFACES] pg_pwd |
| Previous Message | Lamar Owen | 1999-11-20 22:41:34 | Re: [INTERFACES] pg_pwd |