| From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_read_file() and non-ascii input file |
| Date: | 2009-11-30 09:36:05 |
| Message-ID: | 20091130183605.64E5.52131E4D@oss.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> pg_read_file() takes byte-offset and length as arguments,
> but we don't check the result text with pg_verify_mbstr().
> Should pg_read_file() return bytea instead of text or adding
> some codes to verify the input? Only superusers are allowed
> to use the function, but it is still dangerous.
Here is a patch to modify the result type of pg_read_file to bytea.
I think it is a possibly-security hole -- it might be safe because only
supersusers can use the function, but it is still dangerous.
We can still use the function to read a text file:
SELECT convert_from(pg_read_file(...), 'encoding')
If we want to keep backward compatibility, the issue can be fixed
by adding pg_verifymbstr() to the function. We can also have the
binary version in another name, like pg_read_binary_file().
Which solution is better? Comments welcome.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
| Attachment | Content-Type | Size |
|---|---|---|
| pg_read_file_as_bytea.patch | application/octet-stream | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2009-11-30 09:37:43 | Re: draft RFC: concept for partial, wal-based replication |
| Previous Message | Stefan Kaltenbrunner | 2009-11-30 09:32:50 | Re: draft RFC: concept for partial, wal-based replication |