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 cle
Philip Warner <[EMAIL PROTECTED]> 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'
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
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 cours
