Thread: import/export of large objects on server-side
Hi all, at the moment import/export of large objects on server-side only can be activated for all users by editing config.h due to security reasons. My idea is, to enable in for everyone, when using s apecial directory (e.g. /tmp). What do you think about this? Regards, Klaus -- TWC GmbH Schlossbergring 9 79098 Freiburg i. Br. http://www.twc.de
Klaus Reger <K.Reger@twc.de> writes:
> at the moment import/export of large objects on server-side only can be
> activated for all users by editing config.h due to security reasons.
> My idea is, to enable in for everyone, when using s apecial directory (e.g.
> /tmp). What do you think about this?
It'd still be a security hole, and not significantly smaller (consider
symlinks).
Use the client-side LO import/export functions, instead.
regards, tom lane
> Klaus Reger <K.Reger@twc.de> writes: >> at the moment import/export of large objects on server-side only can >> be activated for all users by editing config.h due to security >> reasons. My idea is, to enable in for everyone, when using s apecial >> directory (e.g. /tmp). What do you think about this? > > It'd still be a security hole, and not significantly smaller (consider > symlinks). > > 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. What do you think about this idea? Do you have any other suggestions for serverside lo-ing, without granting every user superuser-privileges? Regards, Klaus
"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:
> 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
> "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
-------- 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
Attachment
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
littledirty feature.
May by add to our privilege system support for LO operations too. Butour current privilege system is very inflexible
forchanges1...
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