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
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 there was
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 the user
Robert Haas wrote:
On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 create a
On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
2009/10/16 KaiGai Kohei kai...@ak.jp.nec.com:
. 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
Greg Stark gsst...@mit.edu 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
On Fri, Oct 16, 2009 at 12:45 PM, Greg Stark gsst...@mit.edu wrote:
2009/10/16 KaiGai Kohei kai...@ak.jp.nec.com:
. 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
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 addition, I
Greg Stark wrote:
2009/10/16 KaiGai Kohei kai...@ak.jp.nec.com:
. 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
KaiGai Kohei kai...@ak.jp.nec.com 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
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com 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
On Thu, Oct 15, 2009 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas wrote:
On Thu, Oct 15, 2009 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us 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
2009/10/13 KaiGai Kohei kai...@ak.jp.nec.com:
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.
Robert Haas robertmh...@gmail.com 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:
Robert Haas wrote:
2009/10/13 KaiGai Kohei kai...@ak.jp.nec.com:
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.
On Wed, Oct 14, 2009 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
20 matches
Mail list logo
