How to give security to pg_catalogs
Hi All,
How to give security to the pg_catalogs, as these are freely alterable and
cause some security problem. Here i mean to say, as a superuser we can
delete the rows from a catalogs are alter the catalogs, is there anyway to
put restriction or any promting before doing anything to catalogs.
Any suggestions for this ?
Regards
Raghavendra
raghavendra t <raagavendra.rao@gmail.com> writes:
How to give security to the pg_catalogs, as these are freely alterable and
cause some security problem. Here i mean to say, as a superuser we can
delete the rows from a catalogs are alter the catalogs, is there anyway to
put restriction or any promting before doing anything to catalogs.
Any suggestions for this ?
Don't give superuser privileges to anyone who's dumb enough to try such
things on a production database.
This is much like the fact that, say, root can trivially destroy any
Unix filesystem. You could imagine trying to put enough training wheels
on superuserdom to prevent such things, but it's not really practical
and any attempt would get in the way of many legitimate uses.
regards, tom lane
Hi Tom,
Thank you for the update
This is much like the fact that, say, root can trivially destroy any
Unix filesystem. You could imagine trying to put enough training wheels
on superuserdom to prevent such things, but it's not really practical
and any attempt would get in the way of many legitimate uses.
Can we create any prompts on the pg_catalogs while doing any operation like
altering/deleting manually.
Regards
Raghavendra
On Mon, Mar 29, 2010 at 8:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
raghavendra t <raagavendra.rao@gmail.com> writes:
How to give security to the pg_catalogs, as these are freely alterable
and
cause some security problem. Here i mean to say, as a superuser we can
delete the rows from a catalogs are alter the catalogs, is there anywayto
put restriction or any promting before doing anything to catalogs.
Any suggestions for this ?Don't give superuser privileges to anyone who's dumb enough to try such
things on a production database.This is much like the fact that, say, root can trivially destroy any
Unix filesystem. You could imagine trying to put enough training wheels
on superuserdom to prevent such things, but it's not really practical
and any attempt would get in the way of many legitimate uses.regards, tom lane