(2009/12/12 6:27), Robert Treat wrote:
>> One point. I'd like to introduce a use case without row-level granularity.
>>
>> The page.24 in this slide:
>>http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf
>>
>> shows SELinux performs as a logical wall between virtual domains in
>
(2009/12/12 21:51), Robert Haas wrote:
2009/12/12 KaiGai Kohei:
I'd like to summary about the framework.
I am not necessarily in agreement with many of the points listed in
this email.
* Functionalities
The ACE framework hosts both of the default PG checks and upcoming
enhanced securities.
(2009/12/12 15:42), "Ing . Marcos Lui's Orti'z Valmaseda" wrote:
> KaiGai Kohei escribio':
>> Stephen Frost wrote:
>>
>>> Josh,
>>>
>>> * Joshua Brindle (met...@manicmethod.com) wrote:
>>>
Stephen Frost wrote:
> I do think that, technically, there's no reason we couldn't allow for
>>>
2009/12/12 KaiGai Kohei :
> I'd like to summary about the framework.
I am not necessarily in agreement with many of the points listed in
this email.
> * Functionalities
>
> The ACE framework hosts both of the default PG checks and upcoming
> enhanced securities. We can build a binary with multipl
KaiGai Kohei escribio':
> Stephen Frost wrote:
>
>> Josh,
>>
>> * Joshua Brindle (met...@manicmethod.com) wrote:
>>
>>> Stephen Frost wrote:
>>>
I do think that, technically, there's no reason we couldn't allow for
multiple "only-more-restrictive" models to be enabled and b
I'd like to summary about the framework.
* Functionalities
The ACE framework hosts both of the default PG checks and upcoming
enhanced securities. We can build a binary with multiple enhanced
security features, but user can choose one from them at most due
to the security label management.
So, i
Stephen Frost wrote:
> Josh,
>
> * Joshua Brindle (met...@manicmethod.com) wrote:
>> Stephen Frost wrote:
>>> I do think that, technically, there's no reason we couldn't allow for
>>> multiple "only-more-restrictive" models to be enabled and built in a
>>> single binary for systems which support i
Stephen Frost wrote:
>> In my cosmetic preference, "ace_" is better than "ac_". The 'e' means
>> extendable, and "ace" feels like something cool. :-)
>
> No complaints here.. I just hope this doesn't end up being *exactly*
> the same as your original PGACE patches.. I'd feel terrible if we
> wer
On Thursday 10 December 2009 21:47:18 KaiGai Kohei wrote:
> Greg Smith wrote:
> > It's funny; we started out this CommitFest with me scrambling to find
> > someone, anyone, willing to review the latest SE-PostgreSQL patch,
> > knowing it was a big job and few were likely to volunteer. Then
> > sch
Josh,
* Joshua Brindle (met...@manicmethod.com) wrote:
> Stephen Frost wrote:
>> I do think that, technically, there's no reason we couldn't allow for
>> multiple "only-more-restrictive" models to be enabled and built in a
>> single binary for systems which support it. As such, I would make those
Stephen Frost wrote:
KaiGai,
I do think that, technically, there's no reason we couldn't allow for
multiple "only-more-restrictive" models to be enabled and built in a
single binary for systems which support it. As such, I would make those
just "#if defined()" rather than "#elif". Let it be
On Fri, 2009-12-11 at 11:36 -0500, Stephen Frost wrote:
[Snip...]
>
> > In addition, OS allows to choose one enhanced security at most eventually.
> >
> > In my image, the hook should be as:
> >
> > Value *
> > ac_database_create([arguments ...])
> > {
> > /*
> >* The default
Greg,
* Greg Smith (g...@2ndquadrant.com) wrote:
> I think we need a two pronged attack on this issue. Eventually I think
> someone who wants this feature in there will need to sponsor someone
> (and not even necessarily a coder) to do a sizable round of plain old
> wording cleanup on the c
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> As Rober Haas already suggested in another message, my patch in the last
> commit fest is too large. It tried to rework anything in a single patch.
> The "per-object-type" basis make sense for me.
Agreed.
> In my cosmetic preference, "ace_" i
Joshua Brindle wrote:
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group o
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> (1) Whether the framework should host the default PG model, not only
>> enhanced security features, or not?
>> This patch tried to host both of the default PG model and SELinux.
>> But, the default PG model
Robert Haas wrote:
One comment I have in general about this process is that I think it
would enormously reduce the level of pain associated with making these
kinds of changes if we could get patches that were not full of minor
issues that need to be cleaned up (like comments not properly
adjusted
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> (1) Whether the framework should host the default PG model, not only
> enhanced security features, or not?
> This patch tried to host both of the default PG model and SELinux.
> But, the default PG model does not have same origin with
Stephen Frost wrote:
> * Greg Smith (g...@2ndquadrant.com) wrote:
>> I personally feel that Steven
>> Frost's recent comments here about how the PostgreSQL code makes this
>> harder than it should be really cuts to the core of a next step here.
>> The problem facing us isn't "is SEPostgreSQL
On Thu, Dec 10, 2009 at 10:39 PM, Stephen Frost wrote:
> Let's start by taking the patch I reviewed and splitting up
> security/access_control.c along object lines. Of course, the individual
> security/_ac.c files would only include the .h's that are
> necessary. This would be a set of much smal
Stephen Frost wrote:
* Greg Smith (g...@2ndquadrant.com) wrote:
I have to be honest and say that I'm not optimistic that this is
possible or even a good idea to accomplish in the time remaining during
this release.
While I agree with you, I wish you hadn't brought it up. :) Mostly
* Greg Smith (g...@2ndquadrant.com) wrote:
> I personally feel that Steven
> Frost's recent comments here about how the PostgreSQL code makes this
> harder than it should be really cuts to the core of a next step here.
> The problem facing us isn't "is SEPostgreSQL the right solution for
>
Greg Smith wrote:
> It's funny; we started out this CommitFest with me scrambling to find
> someone, anyone, willing to review the latest SE-PostgreSQL patch,
> knowing it was a big job and few were likely to volunteer. Then
> schedules lined up just right, and last night I managed to get a gre
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group of people all to
25 matches
Mail list logo
