Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Also, while I'm aware that a superuser can persuade the backend to write > >> on anything, it doesn't follow that we should invent pg_file_write(), > >> pg_file_rename(), or pg_file_unlink(). > > > I think the analogy is locking one door but leaving the other door > > unlocked. > > Not only that, but posting a sign out front telling which door is > unlocked.
Advertising
Actually, my point was that the door is already unlocked (COPY), and preventing write() because it would unlock a door isn't a valid issue. > 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. I do like a full API because I think it could be useful, but I guess we have to decide if allowing more backend capabilities is reasonable. -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
