Re: logfile subprocess and Fancy File Functions

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