Bruce Momjian wrote:
Alvaro Herrera wrote:
Would it make sense to instead of removing and deferring pieces bit by bit to
instead work the other way around? Extract just the part of the patch that
maps SELinux capabilities to Postgres privileges as a first patch? Then
discuss any other parts individually at a later date?
I think that makes sense. Implement just a very basic core in a first
patch, and start adding checks slowly, one patch each. We have talked
about "incremental patches" in the past.
We wouldn't get "unbreakable PostgreSQL" in a single commit, but we
would at least start moving.
The good thing about having started in the opposite direction is that by
now we know that the foundation APIs are good enough to build the
complete feature.
Well, we have been trying to go simplify the SE-PostgreSQL patch since
September, and while we have made progress, we still have work to do,
and at this point I think we have run out of time. I think we have
given it a fair shot, but I don't think it is going to make 8.4.
KaiGai-san, the only option I can offer is perhaps to list a URL for
your SE-PostgreSQL patch to be applied by people who want to use SE-PG.
Needless to say, I'm dissatisfied with this offer. But I can understand
we're paying effort to release the v8.4 on schedule as far as possible,
and we don't have infinite time for development all the items.
Yes, it is possible to accept the offer for me.
Meanwhile, I would not like to repeat same thing in the v8.5 development
cycle again. At the head of this year, we have rest of three big new
features (Sync-replication, Hot-standby and SE-PostgreSQL) but all of
them have been bursted for the v8.4.
In the v8.5 development cycle, I'll pay effort to propose this feature
with smaller part, to build it up step-by-step, as suggested in this
commit fest. So, I would like folks to review and commit it in the
earlier phase.
What is your opinion?
Currently, we have the following action items for the SE-PostgreSQL with
full-functionalities. I'll consider what components can be implemented as
a separated patch again, and submit them at:
http://wiki.postgresql.org/wiki/CommitFest_2009-First
0. Changes in security policy.
- I got a few requirements for the SELinux security policy.
It is necessary to discuss in the SELinux community also.
- *:{select} and *:{use} permission should be integrated
- db_database:{get_param set_param} to be removed
- A new db_database:{superuser} permission
1. Security system columns support
It contains a few sub-facilities, and they can be submitted
in the different patches.
1-1. security system columns and pg_security system catalog
1-2. writable system columns support(security_label and security_acl)
1-3. reclaim unused entries in pg_security system catalog
2. Basic tables/columns-level access controls (dependency: 1-1)
It means the facility proposed in the v8.4 development.
We also need to discuss an issue of ACL_UPDATE/ACL_SELECT_FOR_UPDATE.
3. Row-level access control facilities (dependency: 1-2, 2)
It also provides permission checks in row-level granularity
both of DAC and MAC.
4. Advanced permission support (dependency: 2)
4-1. db_procedure:{install} permission.
Heikki also required similar stuff in the vanilla PostgreSQL.
4-2. db_database:{load_module install_module} permission.
4-3. file:{read write} permission for COPY TO/FROM and others.
4-4. permission checks on the large objects.
(I guess vanilla PostgreSQL also requires it.)
5. Audit support (dependency: 2)
It is not a facility proposed in the v8.4.
SE-PostgreSQL enables to generate audit records for violated accesses.
This facility write them out to system audit daemon.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
