Re: import/export of large objects on server-side
-------- Ursprüngliche Nachricht --------
Betreff: Re: [HACKERS] import/export of large objects on server-side
Von: "Klaus Reger" <K.Reger@twc.de>
An: <tgl@sss.pgh.pa.us>
Use the client-side LO import/export functions, instead.
ok, i've read the config.h and the sources. I agree that this can be a
security hole. But for our application we need lo-access from
PL/PGSQL-Procedures (explicitly on the server). We have to check out
documents, work with them and then check the next version in.Whats about an configuration-file entry, in the matter
LO_DIR=/directory or none (which is the default).
For our product we want to be compatible with the original sources of Pg,
avoiding own patches in every new version.
Hi,
I've made a patch, that introduces an entry in the PostgreSQL-config file.
You can set a drirectory, where all imports/exports can happen. If nothing
is set (the default), no imports/exports on the server-side are allowed.
To enhance the security, no reading/writung is allowed from/to non-regular
files (block-devs, symlinks, etc.)
I hope, that this patch is secure enough and will be integrated.
Regards, Klaus
Attachments:
lo_imp_exp.diffapplication/octet-stream; name=lo_imp_exp.diffDownload+138-13
"Klaus Reger" <K.Reger@twc.de> writes:
I've made a patch, that introduces an entry in the PostgreSQL-config file.
You can set a drirectory, where all imports/exports can happen. If nothing
is set (the default), no imports/exports on the server-side are allowed.
To enhance the security, no reading/writung is allowed from/to non-regular
files (block-devs, symlinks, etc.)
This is trivially defeatable, assuming that the "import/export"
directory is world writable (if it isn't, importing will be tough).
Example: say imp/exp directory is
/var/spool/impexp
Bad guy wants to read/write Postgres-owned file, say
/usr/local/pgsql/data/pg_hba.conf
All he need do is
ln -s /usr/local/pgsql/data /var/spool/impexp/link
and then ask to lo_read or lo_write
/var/spool/impexp/link/pg_hba.conf
which will be allowed since it's a regular file.
Or, even simpler, ask to read/write
/var/spool/impexp/../../../usr/local/pgsql/data/pg_hba.conf
While you could patch around these particular attacks by further
restricting the filenames, the bottom line is that server-side LO
operations are just inherently insecure.
regards, tom lane
"Klaus Reger" <K.Reger@twc.de> writes:
I've made a patch, that introduces an entry in the PostgreSQL-config
file. You can set a drirectory, where all imports/exports can happen.
If nothing is set (the default), no imports/exports on the server-side
are allowed. To enhance the security, no reading/writung is allowed
from/to non-regular files (block-devs, symlinks, etc.)This is trivially defeatable, assuming that the "import/export"
directory is world writable (if it isn't, importing will be tough).
...
While you could patch around these particular attacks by further
restricting the filenames, the bottom line is that server-side LO
operations are just inherently insecure.regards, tom lane
Ok, you're right, but is it acceptable, to configure this, using the
configfile, rather than with a compile-option?
Regards, Klaus
"Klaus Reger" <K.Reger@twc.de> writes:
Ok, you're right, but is it acceptable, to configure this, using the
configfile, rather than with a compile-option?
The patch as given isn't any more secure than just enabling
ALLOW_DANGEROUS_LO_FUNCTIONS, so I for one will vote against
applying it.
I'm still unconvinced that there's any need to create a server-side LO
import/export loophole. Client-side LO operations are inherently safer,
and that's the direction you should be looking in for a solution.
regards, tom lane
On Fri, Nov 16, 2001 at 05:02:13PM +0100, Klaus Reger wrote:
"Klaus Reger" <K.Reger@twc.de> writes:
I've made a patch, that introduces an entry in the PostgreSQL-config
file. You can set a drirectory, where all imports/exports can happen.
If nothing is set (the default), no imports/exports on the server-side
are allowed. To enhance the security, no reading/writung is allowed
from/to non-regular files (block-devs, symlinks, etc.)This is trivially defeatable, assuming that the "import/export"
directory is world writable (if it isn't, importing will be tough)....
While you could patch around these particular attacks by further
restricting the filenames, the bottom line is that server-side LO
operations are just inherently insecure.regards, tom lane
Ok, you're right, but is it acceptable, to configure this, using the
configfile, rather than with a compile-option?
You can always use client-site LO operations without this restriction.
IMHO server-site LO operations is needless and a little dirty feature.
May by add to our privilege system support for LO operations too. But
our current privilege system is very inflexible for changes1...
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz