Re: [RFC] PostgreSQL Access Control Extension (PGACE)
От | KaiGai Kohei |
---|---|
Тема | Re: [RFC] PostgreSQL Access Control Extension (PGACE) |
Дата | |
Msg-id | 4624F69B.6060405@kaigai.gr.jp обсуждение исходный текст |
Ответ на | Re: [RFC] PostgreSQL Access Control Extension (PGACE) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: >> Column level? We don't currently support that, except through VIEWs. >> How is it implemented? > > It wasn't clear to me how much of this is actually working today and how > much is a paper design --- one thing in particular that stood out as > probable handwaving was the bit about being able to assign to a system > column in INSERT or UPDATE. I'm fairly sure that that would take some > *significant* redesign of querytree and plan targetlist representation > :-( ... I looked at it once for OIDs and decided it wasn't worth the > trouble. Currently, writable system column support is already included as a part of PGACE, and it works fine to make setting up SE-PostgreSQL. The implementation uses TargetEntry->resjunk effectively to make it simplified. When a targetlist contains "security_context" column in a UPDATE or INSERT query, SE-PostgreSQL marks the TargetEntry as a junk. Then, the value explicitly given as "security_context" is computed in the normal way. It is fetched at ExecutePlan() just before calling ExecUpdate() or ExecInsert(), and stored into HeapTupleHeader->t_security. Maybe, a part of the patch to implement them is less than 100L, without any significant redesign, Is there any oversight? If so, please tell me. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: