Re: AW: Isn't pg_statistic a security hole?
От | Barry Lind |
---|---|
Тема | Re: AW: Isn't pg_statistic a security hole? |
Дата | |
Msg-id | 3AF82E6E.50106@xythos.com обсуждение исходный текст |
Ответ на | AW: Isn't pg_statistic a security hole? (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
I can say what oracle does in this regard. For information like this Oracle will generally have three views in the data dictionary: 1) USER_XXX - shows records where the current user is the owner of the item in question 2) ALL_XXX - shows records for all items accessible by the current user 3) DBA_XXX - shows records for all items, only available for DBA's or superusers Where XXX are things like: TABLES, VIEWS, TAB_COL_STATISTICS, INDEXES, TRIGGERS, etc (about 120 in all). thanks, --Barry Tom Lane wrote: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > >
В списке pgsql-hackers по дате отправления: