Re: ExecutorCheckPerms() hook

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: ExecutorCheckPerms() hook
Дата
Msg-id 4BFDE068.4010305@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: ExecutorCheckPerms() hook  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: ExecutorCheckPerms() hook  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
[v9.1] add makeRangeTblEntry() into makefuncs.c  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Reworks of DML permission checks  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
[v9.1] Add security hook on initialization of instance  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
Stephen,

>> The 'failure' may make an impression of generic errors not only permission denied.
>> How about 'error_on_violation'?
>
> Maybe 'ereport_on_violation'?  I dunno, guess one isn't really better
> than the other.  You need to go back and fix the comment though- you
> still say 'abort' there.

I have no preference between 'error_on_violation' and 'ereport_on_violation'.
OK, I fixed it.

>> BTW, I wonder whether acl.h is a correct place to explain about the hook,
>> although I added comments for the hook.
>
> Guess I don't really see a problem putting the comments there.  By the
> way, have we got a place where we actually document the hooks we support
> somewhere in the official documentation..?  If so, that should certainly
> be updated too..

I could not find Executor hooks from doc/src/sgml using grep.
If so, it might be worth to list them on the wikipage.

>> I think we should add a series of explanation about ESP hooks in the internal
>> section of the documentation, when the number of hooks reaches a dozen for
>> example.
>
> I believe the goal will be to avoid reaching a dozen hooks for this.

Maybe, all we need to hook on DML permissions is only this one.

> All-in-all, I'm pretty happy with these.  Couple minor places which
> could use some copy editing, but that's about it.
>
> Next, we need to get the security label catalog and the grammar to
> support it implemented and then from that an SELinux module should
> be pretty easy to implement.  Based on the discussions at PGCon, Robert
> is working on the security label catalog and grammar.  The current plan
> is to have a catalog similar to pg_depend, to minimize impact to the
> rest of the backend and to those who aren't interested in using security
> labels.

Pg_depend? not pg_description/pg_shdescription?

I basically agree with the idea that minimizes damages to the existing schema
of system catalogs, but I cannot imagine something like pg_depend well.

I'd like to post a new thread to discuss the security label support. OK?

> Of course, there will also need to be hooks there for an
> external module to enforce restrictions associated with changing labels
> on various objects in the system.

Yes, the user given has to be validated by ESP.

Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: get_whatever_oid, part 1: object types with unqualifed names
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: exporting raw parser