Re: AW: Isn't pg_statistic a security hole? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: Isn't pg_statistic a security hole?
Date
Msg-id 28840.989331916@sss.pgh.pa.us
Whole thread Raw
In response to AW: Isn't pg_statistic a security hole?  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: 7.1.2 schedule (was Re: Posted 7.1 RPMs for Mandrake 7.2)
Next
From: "Rod Taylor"
Date:
Subject: UserLock oddity with Limit