Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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.
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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
