From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sepgsql contrib module |
Date: | 2011-01-20 03:48:16 |
Message-ID: | 4D37B080.6060704@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2011/01/20 12:10), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> How about feasibility to merge this 4KL chunks during the rest of
>> 45 days? I think we should decide this general direction at first.
>
> I read through this code tonight and it looks pretty straightforward.
> I don't see much reason not to accept this more or less as-is. I'm a
> bit suspicious of this line:
>
> { "translation", SEPG_PROCESS__TRANSITION },
>
> I can't help wondering based on the rest of the table whether you
> intend to have the same word on that line twice, but you don't. On a
> related note, would it make sense to pare down this table to the
> entries that are actually used at the moment?
Sorry for giving you a confusion.
It was my typo, so should be fixed as:
{ "transition", SEPG_PROCESS_TRANSITION },
This permission shall be checked when a security label of client being
switched from X to Y, typically on execution of trusted-procedure.
Also, I missed to check on sepgsql_needs_fmgr_hook(). We don't want to
allow inlining the function on lack of permission.
I'll fix them soon.
> And how about adding a
> ProcessUtility_hook to trap evil non-DML statements that some
> nefarious user might issues?
>
It seems to me reasonable as long as the number of controlled command
are limited. For example, LOAD command may be a candidate being
controlled without exceptions.
However, it will be a tough work, if the plug-in tries to parse and
analyze supplied utility commands by itself.
> One other problem is that you need to work on your whitespace a bit.
> I believe in a few places you have a mixture of tabs and spaces. More
> seriously, pgindent is going to completely mangle things like this:
>
> /*
> * sepgsql_mode
> *
> * SEPGSQL_MODE_DISABLED : Disabled on runtime
> * SEPGSQL_MODE_DEFAULT : Same as system settings
> * SEPGSQL_MODE_PERMISSIVE : Always permissive mode
> * SEPGSQL_MODE_INTERNAL : Same as SEPGSQL_MODE_PERMISSIVE,
> * except for
> no audit prints
> */
>
> You have to write it with a line of dashes on the first and last
> lines, if you don't want it reformatted as a paragraph. It might be
> worth actually running pgindent over contrib/selinux and then check
> over the results.
>
OK, I'll try to run pgindent to confirm the effect of reformat.
> Finally, we need to work on the documentation.
>
I uploaded my draft here.
http://wiki.postgresql.org/wiki/SEPostgreSQL_Documentation
If reasonable, I'll move them into *.sgml style.
I may want to simplify the step to installation using an installer
script.
> But overall, it looks pretty good, IMHO.
>
Thanks for your reviewing in spite of a large patch.
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-20 04:01:27 | Re: sepgsql contrib module |
Previous Message | Stephen Frost | 2011-01-20 03:16:51 | REVIEW: EXPLAIN and nfiltered |