I propose that initdb should do
	REVOKE ALL on pg_largeobject FROM public
same as it does already for pg_shadow and pg_statistic.  This would
prevent non-superusers from examining or modifying large objects
except through the LO operations.

This is only security through obscurity, of course, since any user can
still read or modify another user's LO if he can guess its OID.  But
security through obscurity is better than no security at all.  (Perhaps
someday the LO operations will be enhanced to perform access-rights
checks.  I have no interest in doing that work right now, however.)

			regards, tom lane

Wed, 27 Jun 2001 12:27:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
pg_largeobject is a security hole
At 12:27 27/06/01 -0400, Tom Lane wrote:
>I propose that initdb should do
>	REVOKE ALL on pg_largeobject FROM public
>

May have an issue with PG_DUMP, which does a 'select oid from
pg_largeobject', I think.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Thu, 28 Jun 2001 09:17:42 +1000
Philip Warner <pjw@rhyme.com.au>
Re: pg_largeobject is a security hole
Philip Warner <pjw@rhyme.com.au> writes:
> At 12:27 27/06/01 -0400, Tom Lane wrote:
>> I propose that initdb should do
>> REVOKE ALL on pg_largeobject FROM public

> May have an issue with PG_DUMP, which does a 'select oid from
> pg_largeobject', I think.

Hmm.  [sound of grepping]  So does psql's \lo_list command.  That's
annoying ... the list of large object OIDs is *exactly* what you'd want
to hide from the unwashed masses.  Oh well, I'll leave bad enough alone
for now.

			regards, tom lane

Wed, 27 Jun 2001 19:49:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_largeobject is a security hole 
At 19:49 27/06/01 -0400, Tom Lane wrote:
>
>Hmm.  [sound of grepping]  So does psql's \lo_list command.  That's
>annoying ... the list of large object OIDs is *exactly* what you'd want
>to hide from the unwashed masses.  Oh well, I'll leave bad enough alone
>for now.
>

I suspect this would be cleaned up when/if we implement LOB LOCATORs: they
have a limited lifetime, should be the only way to retrieve LOBs, and could
hide the underlying OID (which would never be used by external interfaces).


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Thu, 28 Jun 2001 09:54:14 +1000
Philip Warner <pjw@rhyme.com.au>
Re: pg_largeobject is a security hole 