pg_largeobject is a security hole
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
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 |/
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
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 |/