Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> When we create a new object, we can provide an explicit security context
>> to be assigned on the new object, instead of the default one.
>
> To get started, do we really need that feature? It would make for a
> significantly smaller patch if ther
KaiGai Kohei wrote:
> When we create a new object, we can provide an explicit security context
> to be assigned on the new object, instead of the default one.
To get started, do we really need that feature? It would make for a
significantly smaller patch if there was no explicit security labels on
Robert Haas wrote:
> On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
> wrote:
>> This raises an important point: We need *developer documentation* on how
>> to write SE-Pgsql compliant permission checks. Not only for authors of
>> 3rd party modules but for developers of PostgreSQL itself. Poin
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> 1) creation of a database object
>>
>> In SELinux model, when a user tries to create a new object (not limited
>> to database object, like a file or socket), a default security context
>> is assigned on the new object, then SELinux checks whether t
On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
wrote:
> This raises an important point: We need *developer documentation* on how
> to write SE-Pgsql compliant permission checks. Not only for authors of
> 3rd party modules but for developers of PostgreSQL itself. Point 2)
> above needs to be e
KaiGai Kohei wrote:
> 1) creation of a database object
>
> In SELinux model, when a user tries to create a new object (not limited
> to database object, like a file or socket), a default security context
> is assigned on the new object, then SELinux checks whether the user has
> privileges to crea
Greg Stark wrote:
2009/10/16 KaiGai Kohei :
. In addition, I already tried to put SE-PG hooks
within pg_xxx_aclchecks() in this CF, but it was failed due to the
differences in the security models.
I thought the last discussion ended with a pretty strong conclusion
that we didn't want differenc
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> The purpose of this patch is to provide function entrypoints for the
>> upcoming SE-PostgreSQL feature, because I got a few comments that we
>> hesitate to put sepgsql_xxx() hooks on the main routines directly in
>> the first commit fest. In additi
On Fri, Oct 16, 2009 at 12:45 PM, Greg Stark wrote:
> 2009/10/16 KaiGai Kohei :
>> . In addition, I already tried to put SE-PG hooks
>> within pg_xxx_aclchecks() in this CF, but it was failed due to the
>> differences in the security models.
>
> I thought the last discussion ended with a pretty st
Greg Stark writes:
> The first step is to add hooks which don't change the security model
> at all, just allow people to control the existing checks from their SE
> configuration.
This is in fact what the presented patch is meant to do. The issue is
about whether the hook placement is sane/usefu
2009/10/16 KaiGai Kohei :
> . In addition, I already tried to put SE-PG hooks
> within pg_xxx_aclchecks() in this CF, but it was failed due to the
> differences in the security models.
I thought the last discussion ended with a pretty strong conclusion
that we didn't want differences in the securi
KaiGai Kohei wrote:
> The purpose of this patch is to provide function entrypoints for the
> upcoming SE-PostgreSQL feature, because I got a few comments that we
> hesitate to put sepgsql_xxx() hooks on the main routines directly in
> the first commit fest. In addition, I already tried to put SE-PG
Robert Haas wrote:
> On Thu, Oct 15, 2009 at 1:22 PM, Tom Lane wrote:
>> Maybe if I weren't burned out after a month of CommitFesting, I could
>> muster a more positive reaction, but right now I just can't summon any
>> enthusiasm for this.
>
> Based on this review, I am marking this patch Reject
On Thu, Oct 15, 2009 at 1:22 PM, Tom Lane wrote:
> Maybe if I weren't burned out after a month of CommitFesting, I could
> muster a more positive reaction, but right now I just can't summon any
> enthusiasm for this.
Based on this review, I am marking this patch Rejected.
For what it's worth, I
Tom Lane wrote:
> KaiGai Kohei writes:
>> [ patch r2363 ]
>
> I promised I would review this today, but I just can't make myself do it
> in any detail. This is too large, too ugly, and it is going in a
> direction that I do not like or want to spend any of my time on.
>
> The overwhelming impre
KaiGai Kohei writes:
> [ patch r2363 ]
I promised I would review this today, but I just can't make myself do it
in any detail. This is too large, too ugly, and it is going in a
direction that I do not like or want to spend any of my time on.
The overwhelming impression after a brief read-throug
On Wed, Oct 14, 2009 at 9:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> Are any of the committers willing to take a look at this? Tom?
>
> I do plan to look at it tomorrow.
Oh, great. You've done an impressive job slogging through a bunch of
big, complex patches in the last week.
Thanks,
.
Robert Haas wrote:
> 2009/10/13 KaiGai Kohei :
>> The attached patch is a revised one with the following updates:
>
> Despite two fairly explicit requests, this patch (and, with the
> exception of ECPG, only this patch) has not yet been reviewed by a
> committer.
>
> http://archives.postgresql.or
Robert Haas writes:
> Are any of the committers willing to take a look at this? Tom?
I do plan to look at it tomorrow.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
2009/10/13 KaiGai Kohei :
> The attached patch is a revised one with the following updates:
Despite two fairly explicit requests, this patch (and, with the
exception of ECPG, only this patch) has not yet been reviewed by a
committer.
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00591.p
20 matches
Mail list logo
