Re: ExecutorCheckPerms() hook

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: ExecutorCheckPerms() hook
Дата
Msg-id AANLkTin02nFfX2mcpP2Za2wy3JDMd_aOS82aePx3a3eQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ExecutorCheckPerms() hook  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ExecutorCheckPerms() hook  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, May 20, 2010 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> In yesterday's development meeting, we talked about the possibility of
>> a basic SE-PostgreSQL implementation that checks permissions only for
>> DML.  Greg Smith offered the opinion that this could provide much of
>> the benefit of SE-PostgreSQL for many users, while being much simpler.
>>  In fact, SE-PostgreSQL would need to get control in just one place:
>> ExecCheckRTPerms.  This morning, Stephen Frost and I worked up a quick
>> patch showing how we could add a hook here to let a hypothetical
>> SE-PostgreSQL module get control in the relevant place.  The attached
>> patch also includes a toy contrib module showing how it could be used
>> to enforce arbitrary security policy.
>
> Hm, I think you need to ignore RT entries that have no requiredPerms
> bits set.  (Not that it matters too much, unless you were proposing to
> actually commit this contrib module.)

Well, that's an easy change - just out of curiosity, how do we end up
with RT entries with no requiredPerm bits set?

As for committing it, I would definitely like to commit the actual
hook.  If we want the hook without the contrib module that's OK with
me, although I generally feel it's useful to have examples of how
hooks can be used, which is why I took the time to produce a working
example.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ExecutorCheckPerms() hook
Следующее
От: Robert Creager
Дата:
Сообщение: Fwd: PGBuildfarm member polecat Branch HEAD Status changed from StartDb-C:2 failure to StartDb-C:3 failure