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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: Isn't pg_statistic a security hole?
Дата
Msg-id 28840.989331916@sss.pgh.pa.us
обсуждение исходный текст
Ответ на AW: Isn't pg_statistic a security hole?  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: 7.1.2 schedule (was Re: Posted 7.1 RPMs for Mandrake 7.2)
Следующее
От: "Rod Taylor"
Дата:
Сообщение: UserLock oddity with Limit