Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options;  we don't remove features via
configure unless it is for some platform-specific reason.  Please remove
the configure option and make it always enabled.
OK, I'll update it in the next patch set.
Good.  I assume the SQL-row security patch is not testable alone with
out the rest of the patches, right?
The minimum requirements are the 1st and 2nd patches.
The first provides security hooks to PostgreSQL server program, and
the other provides ones to pg_dump command.
The 3rd, 4th and 5th are not necessary for the test purpose.

First, let me say you have done an amazing job of producing patches for
us, and your code quality is very high, especially considering the
complexity of this code and your newness to our development process. My
compliments to NEC, your employer.

Also, I personally am excited about this code and what it will add to
Postgres 8.4.

I hate to ask for something else from you, but I am trying to figure out
how we can proceed in reviewing and applying your additions.  I am
wondering if you can produce a patch that has the SE-Linux part separate
so I can review the non-SE-Linux parts of the patch alone --- right now
I am not 100% clear on what parts are always active as row-level SQL
security and what needs SE-Linux to operate.  I know this is an
additional burden on you and if it is too much to ask, please tell me.

All the SELinux specific part is stored within:
 - src/include/security/sepgsq.h
 - src/backend/security/sepgsql/*
 - Blocks enclosed by "#if defined(HAVE_SELINUX)"
   in src/include/security/pgace.h

SELinux related codes are never invoked without pgaceXXXX() hooks,
so you can simply ignore the above files/parts when you are under
the reviewing to non-SELinux parts.
Rest of changes are commonly needed to manage security attribute
and to inject security hooks.

In all honesty, I hesitate to separate the patch again into two
parts to be integrated later. I would be happy, if you suggested
it a half year ago, because this feature was suggested as two
separated patches in CommitFest:May. :(

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>

--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to