Re: AW: Isn't pg_statistic a security hole?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Isn't pg_statistic a security hole?
Date: 2001-05-08 14:25:16
Message-ID: 28840.989331916@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> How about letting them see all statistics where they have select permission
> on the base table (if that is possible with the new permission table) ?

Yeah, I was thinking the same thing. If we restrict the view on the
basis of current_user being the owner, then we'd have the annoying
problem that superusers *couldn't* use the view for tables they didn't
own.

To implement this, we'd need a SQL function that answers the question
"does user A have read permission on table B?", which is something that
people have asked for in the past anyway. (The existing SQL functions
for manipulating ACLs are entirely unhelpful for determining this.)

Someone needs to come up with a spec for such a function --- do we
specify user and table by names or by OIDs, how is the interesting
permission represented, etc. Is there anything comparable defined by
SQL99 or in other DBMSes?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-05-08 14:29:53 Re: Changes needed to build on NetBSD
Previous Message Tom Lane 2001-05-08 14:16:32 7.1.2 schedule (was Re: Posted 7.1 RPMs for Mandrake 7.2)