Re: [PATCH] SE-PgSQL/tiny rev.2193

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] SE-PgSQL/tiny rev.2193
Дата
Msg-id 603c8f070907201426v21f64299m9a0e66dd306a415b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SE-PgSQL/tiny rev.2193  (Joshua Brindle <method@manicmethod.com>)
Ответы Re: [PATCH] SE-PgSQL/tiny rev.2193  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
On Mon, Jul 20, 2009 at 3:44 PM, Joshua Brindle<method@manicmethod.com> wrote:
> Ron Mayer wrote:
>>
>> Joshua Brindle wrote:
>>>
>>> How many people are you looking for? Is there a number or are you
>>> waiting for a good feeling?
>>
>> <snip>
>
>> Joshua - if you're still associated with Tresys - could someone
>> who could speak for that company say what they think about this
>> project?   The seem quite in-the-loop on what SELinux customers
>> want.
>
> I am capable of speaking for Tresys in this matter. We are very interested
> in this work and our US DoD customers need the capabilities that this
> project adds (assuming row level access controls are a possibility).

This is very interesting, if by "interested" you mean that you are
willing to commit time, money, and development resources to make it
happen.  If by "interested" you mean that you will use it if someone
else does the work of implementing it, that's nice, but fundamentally
doesn't help us very much.

At least in my view, the problem with this patch set is that it's not
committable, and it's not measurably closer to being committable than
it was a year ago. I am not saying (and I don't necessarily think
ANYONE is saying) "this is a great patch, but I don't want to commit
it because I hate SE-Linux".  What I at least am saying is that this
patch has serious problems that need to be fixed in order for it to be
committed, and because KaiGai has not been able to fix those problems
after over a year of back and forth, a new approach is needed here or
we are dead in the water.

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

But I think the following things probably should be:

- tables
- columns
- sequences
- functions
- schemas
- databases
- tablespaces

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.

To restate my basic point: The problem with this patch is that there
are plenty of people who are interested in *having* it, but the only
person who seems to be interested in *writing* it is KaiGai, and that
isn't working.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex
Следующее
От: gabrielle
Дата:
Сообщение: Re: Commitfest Code Sprint with PUGs