Re: User-Id Tracking when Portal was started
| От | Robert Haas |
|---|---|
| Тема | Re: User-Id Tracking when Portal was started |
| Дата | |
| Msg-id | CA+Tgmobwff9vmkAOge=OrtyDbQgQ_F5oUfp=BhOzo3xxoq2Vcg@mail.gmail.com обсуждение исходный текст |
| Ответ на | User-Id Tracking when Portal was started (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
| Ответы |
Re: User-Id Tracking when Portal was started
|
| Список | pgsql-hackers |
On Mon, Jul 2, 2012 at 10:55 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > The attached patch is delivered from the discussion around row-level > access control feature. A problem Florian pointed out is refcursor > declared in security definer function. Even though all the permission > checks are applied based on privilege of the owner of security-definer > function in case when it tries to define a cursor bound to a particular > query, it shall be executed under the credential of executor. > In the result, "current_user" or "has_table_privilege()" will return > unexpected result, even if it would be used in as a part of security > policy for each row. Why not just save and restore the user ID and security context unconditionally, instead of doing this kind of dance? + if (portal->userId != GetUserId()) + SetUserIdAndSecContext(portal->userId, portal->secCo + else + saveUserId = InvalidOid; -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: