Re: BUG #4350: 'select' acess given to views containing "union all" even though user has no grants
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #4350: 'select' acess given to views containing "union all" even though user has no grants |
Дата | |
Msg-id | 48A090CA.8090104@enterprisedb.com обсуждение исходный текст |
Ответ на | BUG #4350: 'select' acess given to views containing "union all" even though user has no grants ("Brendan O'Shea" <boshea@akamai.com>) |
Ответы |
Re: BUG #4350: 'select' acess given to views containing "union all" even though user has no grants
|
Список | pgsql-bugs |
Brendan O'Shea wrote: > There appears to be a bug in the way that permissions are determined for > views that contain "UNION ALL" in their definition. > > There is a simple test case to reproduce the bug. > > 1) As a superuser create the following objects: > > CREATE ROLE test_perm LOGIN PASSWORD 'test_perm'; > > CREATE OR REPLACE VIEW public.simple_select AS SELECT 1; > CREATE OR REPLACE VIEW public.union_all AS SELECT 1 UNION ALL SELECT 2; > > > 2) Now log in as the test_perm user and run the following SQL: > > select * from public.simple_select; > select * from public.union_all; > > The first SQL statement correctly produces an error, but the second > statement will return results with no error, it should instead generate a > permission error. Hmm, looks like pull_up_subqueries somehow loses the range table entry referring the original view. It's reproducible on PG version 8.2 and higher, 8.1 seems to work. I'll dig deeper tomorrow, unless someone else beats me to it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: