From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Joshua Brindle <method(at)manicmethod(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
Subject: | Re: [PATCH] SE-PgSQL/tiny rev.2193 |
Date: | 2009-07-21 00:40:20 |
Message-ID: | 4A650E74.1090100@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> I have attempted, on the relevant threads, to enumerate those problems
> as I see them. Mainly they have to do with hooks all over the code in
> strange and unmaintainable places, documentation that is written in
> poor English and is not easily understandable by people who are not
> already experts in SE-Linux, and a complete inability to get a patch
> that implements a useful subset of the total realm of SE-Linux
> desiderata that more or less matches up with what the existing
> PostgreSQL permissions structure already does. What we've established
> so far is that the following things should NOT be in the list of
> permissions that we attempt in the initial patch:
>
> - row-level security
> - complex DDL permissions
Is the complex DDL permissions mean something like db_xxx:{create},
db_xxx:{relabelfrom relabelto} and others?
If so, I can agree to implement these checks at the later patch.
However, please note that the initial patch cannot achieve actual
security in this case, because it means anyone can change security
label of objects.
> But I think the following things probably should be:
>
> - tables
> - columns
> - sequences
> - functions
> - schemas
> - databases
> - tablespaces
I also think it is reasonable to apply access controls on the types
of object classes at the initial pach.
> I'd be willing to negotiate on all but the first.
>
> I also agree with Peter's contention that a spec would be useful. If
> you could read a clear description of what the patch was going to do,
> then you could separate the problem of figuring out whether that was
> the right thing from the question of whether the patch actually did
> it.
I can also agree with the suggestion.
The specifications (from viewpoint of the developer) will introduces
the fundamental principles to be implemented, and it will figure out
what implementation is better.
As I noted before, I've been flexible about how SE-PgSQL is implemented
as far as it can perform SELinux's security model correctly.
Please for a several days. I'll describe it.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-07-21 01:11:37 | Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex |
Previous Message | Andrew Dunstan | 2009-07-20 23:42:23 | Re: COPY WITH CSV FORCE QUOTE * |