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