Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> As for the analogy to COPY, the addition of unlink/rename to a hacker's > >> tool set renders the situation far more dangerous than if he only has > >> write. Write will not allow him to hack write-protected files, but he > >> might be able to rename them out of the way and create new trojaned > >> versions... > > > Yes, I realized that later, that rename/unlink is based on the directory > > permissions, not the file permissions. That is clearly a new capability > > that could be seen as opening a new door. > > > However, file creation via COPY is based on the directory permissions > > too. > > Right, but the point is that a write-protected file in a writable > directory is not vulnerable to an attacker armed only with write(). > If he can do rename() or delete() then it *is* vulnerable. This is > quite relevant to Postgres seeing that it's hardly practical to > make the $PGDATA directory non-writable to the postmaster, while one > might well think it worthwhile to make pg_hba.conf non-writable.
Yes, I was quoting: > >> SELECT pg_file_unlink('postgresql.conf.bak'); > >> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...'); > >> SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.conf', > >> 'postgresql.conf.bak'); > >> SELECT pg_reload_conf(); The pg_file_write() doesn't open any new security holes, only rename and unlink. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org