Peter Eisentraut wrote:
On Friday 12 December 2008 19:09:26 Alvaro Herrera wrote:
I don't understand -- why wouldn't we just have two columns, one for
plain row-level security and another for whatever security system the
platforms happens to offer? If we were to follow that route, we could
have
On Friday 12 December 2008 19:31:11 Robert Haas wrote:
> Not really. I'm not an SELinux expert. But typically the two do
> exist alongside one another. For example, installing SELinux (MAC)
> does on your system does not make "chmod g+w file" (DAC) stop working;
> it merely performs an ADDITIONA
On Friday 12 December 2008 19:09:26 Alvaro Herrera wrote:
> I don't understand -- why wouldn't we just have two columns, one for
> plain row-level security and another for whatever security system the
> platforms happens to offer? If we were to follow that route, we could
> have row-level security
Bruce Momjian wrote:
KaiGai Kohei wrote:
Also, having the per-row value always be present in the row and
controlled by the bitmask seems ideal; it avoids having to add a CREATE
TABLE option.
Sorry, I don't understand why it related to a CREATE TABLE option.
System columns are always allocated
Bruce Momjian wrote:
KaiGai Kohei wrote:
If we use some type of integer, I suggest using this structure for
pg_security:
CREATE TABLE pg_security(
relid oid,
secid int2,
secacl aclitem[],
secext TEXT
);
This allows the per-row value to be a simple int2. It also imp
Robert Haas wrote:
Peter made an excellent point a few emails upthread: there seemed to
be consensus in the September CommitFest that we needed SQL-level
support for row and column level security before we talked about
implementing those features as part of SELinux. I don't see that
we're any cl
Robert Haas wrote:
I tried to summarize the proposed options, as follows:
o : meritx : demeritX : unacceptable demerit
* 1 security system column, 1 security feature (DAC or MAC)
o It suitable for a single security system column implementation.
x If a user want to use both of DAC and
KaiGai Kohei wrote:
> >>> Also, having the per-row value always be present in the row and
> >>> controlled by the bitmask seems ideal; it avoids having to add a CREATE
> >>> TABLE option.
> >> Sorry, I don't understand why it related to a CREATE TABLE option.
> >> System columns are always allocat
KaiGai Kohei wrote:
> > If we use some type of integer, I suggest using this structure for
> > pg_security:
> >
> > CREATE TABLE pg_security(
> > relid oid,
> > secid int2,
> > secacl aclitem[],
> > secext TEXT
> > );
> >
> > This allows
On Fri, Dec 12, 2008 at 11:57 AM, Gregory Stark wrote:
>> Obviously sandwhiching two values in one column is not going to work.
>> The only question here is whether it's important to simultaneously
>> support both DAC and MAC. As far as I can see, KaiGai is the only one
>> arguing that we don't n
>> Peter made an excellent point a few emails upthread: there seemed to
>> be consensus in the September CommitFest that we needed SQL-level
>> support for row and column level security before we talked about
>> implementing those features as part of SELinux. I don't see that
>> we're any closer t
Robert Haas escribió:
> Peter made an excellent point a few emails upthread: there seemed to
> be consensus in the September CommitFest that we needed SQL-level
> support for row and column level security before we talked about
> implementing those features as part of SELinux. I don't see that
>
"Robert Haas" writes:
> Obviously sandwhiching two values in one column is not going to work.
> The only question here is whether it's important to simultaneously
> support both DAC and MAC. As far as I can see, KaiGai is the only one
> arguing that we don't need to do that (except for Tom, who
> I tried to summarize the proposed options, as follows:
>
> o : meritx : demeritX : unacceptable demerit
>
> * 1 security system column, 1 security feature (DAC or MAC)
> o It suitable for a single security system column implementation.
> x If a user want to use both of DAC and MAC concu
Peter Eisentraut wrote:
KaiGai Kohei wrote:
I would like to be able to assign SQL-level ACLs and SELinux labels
to the same row at the same time in the same build, and have the
system enforce both on top of each other.
In my opinion, it makes more pains (user-interface, performance,
complexi
> If we use some type of integer, I suggest using this structure for
> pg_security:
>
> CREATE TABLE pg_security(
> relid oid,
> secid int2,
> secacl aclitem[],
> secext TEXT
> );
>
> This allows the per-row value to be a sim
KaiGai Kohei wrote:
I would like to be able to assign SQL-level ACLs and SELinux labels to
the same row at the same time in the same build, and have the system
enforce both on top of each other.
In my opinion, it makes more pains (user-interface, performance, complexity
of implementation and s
Peter Eisentraut wrote:
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based
row acces
KaiGai Kohei wrote:
We are going to need to come up with specific answers to these issues
soon.
The origion of issue is simple.
Whether we should support to activate (not only compile) two or more
security
mechanism in same time, or not.
In my opinion, it is not a frequent situation, and it
KaiGai Kohei wrote:
How frequently does someone want to *work* (not compile) DAC and MAC
in same time?
My expectation would be Always.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
This would effectively create a limit on the number of rows per table.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based
row access control at the same tim
Bruce Momjian wrote:
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
The reason why I decided to put an integer value on HeapTupleHeader,
as "oid" doing, is that it has to be modified after simple_heap_i
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > We have had discussion on whether we want one or two security columns;
> > there have been comments on both sides.
>
> It is quite natural end-user should be able to choose one of provided
> security mechanisms, in my opinion. It means user (administ
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > In general, I am concerned that the SE-Linux patch is not converging on
> > a community consensus in terms of user interface or implementation
> > details. This suggests that the patch might not succeed in being
> > included in Postgres 8.4, which is
Bruce Momjian wrote:
In general, I am concerned that the SE-Linux patch is not converging on
a community consensus in terms of user interface or implementation
details. This suggests that the patch might not succeed in being
included in Postgres 8.4, which is a shame.
It is extreamly worst.
I
Bruce Momjian wrote:
We have had discussion on whether we want one or two security columns;
there have been comments on both sides.
It is quite natural end-user should be able to choose one of provided
security mechanisms, in my opinion. It means user (administrator) allows
his prefered securit
We have had discussion on whether we want one or two security columns;
there have been comments on both sides.
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
If we use some type of integer, I suggest us
In general, I am concerned that the SE-Linux patch is not converging on
a community consensus in terms of user interface or implementation
details. This suggests that the patch might not succeed in being
included in Postgres 8.4, which is a shame.
We are going to need to come up with specific ans
Peter Eisentraut wrote:
> On Thursday 11 December 2008 20:32:25 Tom Lane wrote:
> > Well, the objection I was raising is that they should control the same
> > thing. Otherwise we are simply inventing an invasive, high-cost,
> > nonstandard(*) feature that we have had zero field demand for.
>
> Th
> This idea allows to compile two or more security mechanism in the same binary,
> and adds a configuration parameter to choose a security mechanism on its
> startup
> time. So, a single security mechanism chosen works in same time, but multiple
> security mechanisms are built in compile time.
Th
KaiGai Kohei wrote:
I understood objections for "enable/disable something on compile-time"
approach. The following items are my revised proposal.
It does not conflicts to the policy Peter said before in this thread.
Items to be revised:
- It allows to compile multiple security mechanis within a
I understood objections for "enable/disable something on compile-time"
approach. The following items are my revised proposal.
It does not conflicts to the policy Peter said before in this thread.
Items to be revised:
- It allows to compile multiple security mechanis within a single binary.
- It
KaiGai Kohei wrote:
Gregory Stark wrote:
Peter Eisentraut writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based
row access
Gregory Stark wrote:
Peter Eisentraut writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same t
Peter Eisentraut wrote:
On Thursday 11 December 2008 20:32:25 Tom Lane wrote:
Well, the objection I was raising is that they should control the same
thing. Otherwise we are simply inventing an invasive, high-cost,
nonstandard(*) feature that we have had zero field demand for.
There is certain
Aidan Van Dyk wrote:
> Simlarly, SElinux is going to be used *on top* of any application that's
> out there, to try and enfoce the "no data coming in from a secure input"
> leaves through a "less secure output", irrespective of what app level
> security (and in this case, app-level being the SQL/SC
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same time. Isn't this exactl
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it
should
be manipulable by either SQL commands or
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise y
On Thursday 11 December 2008 21:44:39 Gregory Stark wrote:
> > Because we want to use SQL-based row access control and SELinux-based row
> > access control at the same time. Isn't this exactly one of the
> > objections upthread? Both must be available at the same time.
>
> Well I don't think anyo
On Thursday 11 December 2008 20:32:25 Tom Lane wrote:
> Well, the objection I was raising is that they should control the same
> thing. Otherwise we are simply inventing an invasive, high-cost,
> nonstandard(*) feature that we have had zero field demand for.
There is certainly a rather big field
* Gregory Stark [081211 14:47]:
> Peter Eisentraut writes:
>
> > On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
> >> > How can we stick all of these in the same column at the same time?
> >>
> >> Why would we want to?
> >
> > Because we want to use SQL-based row access control and SELinux
Peter Eisentraut writes:
> On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
>> > How can we stick all of these in the same column at the same time?
>>
>> Why would we want to?
>
> Because we want to use SQL-based row access control and SELinux-based row
> access control at the same time. I
Tom Lane wrote:
> Bruce Momjian writes:
> > Let me outline the simplest API, assuming we are using table-level
> > granularity for the security columns.
> > CREATE TABLE would support
> > WITH (ROWACL = TRUE/FALSE);
> > for row-level acl and:
> > WITH (SECEXT = TRUE/FALSE);
> > for SE-Linu
Peter Eisentraut writes:
> On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
>>> How can we stick all of these in the same column at the same time?
>>
>> Why would we want to?
> Because we want to use SQL-based row access control and SELinux-based row
> access control at the same time. Isn
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
> > How can we stick all of these in the same column at the same time?
>
> Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same time. Isn't this exactly one of the objectio
Peter Eisentraut wrote:
> On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> > The idea is that the security columns will hold an OID and the OID will
> > point to a row in a table that contains the security rights/ACL for the
> > column, with multiple rows using the same rights OID.
>
>
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
> Peter Eisentraut wrote:
> > On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
> >> I think there should be only *one* underlying column and that it should
> >> be manipulable by either SQL commands or selinux. Otherwise you're
> >> ma
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
>> I think there should be only *one* underlying column and that it should
>> be manipulable by either SQL commands or selinux. Â Otherwise you're
>> making a lie of the primary argument for having
On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> The idea is that the security columns will hold an OID and the OID will
> point to a row in a table that contains the security rights/ACL for the
> column, with multiple rows using the same rights OID.
That sounds somewhat scary for a nu
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie of the primary argument for having the SQL feature at all.
Well
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
> I think there should be only *one* underlying column and that it should
> be manipulable by either SQL commands or selinux. Otherwise you're
> making a lie of the primary argument for having the SQL feature at all.
Well, an SQL-manipulated r
> I think there should be only *one* underlying column and that it should
> be manipulable by either SQL commands or selinux. Otherwise you're
> making a lie of the primary argument for having the SQL feature at all.
I agree that we're getting pretty far afield from the original
proposal, but I d
On Thursday 11 December 2008 17:43:38 KaiGai Kohei wrote:
> In addition, I want folks to remind that the Row-level ACLs are not
> designed based on SQL standards. Thus, I called it one of the enhanced
> securities.
We have a lot of things in our code that are nonstandard, beyond the standard,
enh
Bruce Momjian wrote:
At this point I am so confused I don't have any response.
Are you discussing the case when we start a PostgreSQL with $PGDATA
generated by different binary?
At first, please consider the case when we start SE-PostgreSQL with
$PGDATA generated by vanilla binary.
(1) In this
On Thursday 11 December 2008 04:52:51 Bruce Momjian wrote:
> > > We do have a per-row HEAP_HASOID bit, so I wonder if we can have a
> > > HEAP_HASSEC bit too. Right now the HEAP_HASOID is controlled by the
> > > CREATE/ALTER table;
> >
> > The current patch add HEAP_HASSECURITY bit to t_infomask.
Zeugswetter Andreas OSB sIT wrote:
> Please reread with above correction,
> and I'll also try a little differently:
>
> Since a pg_security row already represents a combination of rights
> within selinux, I do not really see why that cannot be extended to "a
> combination
> of rowacl and selinux
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Let me outline the simplest API, assuming we are using table-level
>> granularity for the security columns.
>> CREATE TABLE would support
>> WITH (ROWACL = TRUE/FALSE);
>> for row-level acl and:
>> WITH (SECEXT = TRUE/FALSE);
>> for SE-Linux,
> > > > > Ah, that is a good point, that if we have "security
> column" which is
> > > > > usually null then we are requiring the NULL bitmask.
> >
> > Yes, I think that would not be optimal, thus I think "WITH
> > SECURITY_CONTEXT" is needed.
> >
> > > I sure wish others were adding ideas to th
At this point I am so confused I don't have any response.
---
KaiGai Kohei wrote:
> >> But SE-PostgreSQL does not need its table option to control
> >> its availability per table granuality due to its security model.
> >>
>
Bruce Momjian wrote:
> The idea is that the security columns will hold an OID and the OID will
> point to a row in a table that contains the security rights/ACL for the
> column, with multiple rows using the same rights OID. If you change the
> rights on the column the code has to check the exist
>> But SE-PostgreSQL does not need its table option to control
>> its availability per table granuality due to its security model.
>>
>> Database ACL is a kind of DAC. It allows resource owners to
>> set up its access rights. In other hand, SE-PostgreSQL is an
>> implementation of MAC. It does not
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> I have a plan to add a new field (declared as "int2 relrowacl") into
> pg_class to show what column stores its Row-level ACLs.
If you want the column to be "hidden" in the same way that system
columns are, I'm afraid this is a pretty bad idea. There are
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Let me outline the simplest API, assuming we are using table-level
> granularity for the security columns.
> CREATE TABLE would support
> WITH (ROWACL = TRUE/FALSE);
> for row-level acl and:
> WITH (SECEXT = TRUE/FALSE);
> for SE-Linux, with '
Zeugswetter Andreas OSB sIT wrote:
>
> > > > Ah, that is a good point, that if we have "security column" which is
> > > > usually null then we are requiring the NULL bitmask.
>
> Yes, I think that would not be optimal, thus I think "WITH
> SECURITY_CONTEXT" is needed.
>
> > I sure wish others we
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> KaiGai Kohei wrote:
> >CREATE TABLE t (
> >a int,
> >b text
> >) WITH (ROW_LEVEL_ACL=ON);
> >
> > Let me outline the simplest API, assuming we are using table-level
> > granularity
Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
CREATE TABLE t (
a int,
b text
) WITH (ROW_LEVEL_ACL=ON);
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
CREATE TABLE would support
WITH (R
Bruce Momjian wrote:
> Let me outline the simplest API, assuming we are using table-level
> granularity for the security columns.
>
> CREATE TABLE would support
>
> WITH (ROWACL = TRUE/FALSE);
>
> for row-level acl and:
>
> WITH (SECEXT = TRUE/FALSE);
>
> for SE-Linux, with 'SECEXT
Bruce Momjian wrote:
> KaiGai Kohei wrote:
> > >>CREATE TABLE t (
> > >>a int,
> > >>b text
> > >>) WITH (ROW_LEVEL_ACL=ON);
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
CREATE TABLE would support
WIT
KaiGai Kohei wrote:
> >>> Here is our OID column on some rows but not others:
> >>>
> >>> test=> CREATE TABLE test (x INT) WITH oids;
> >>> CREATE TABLE
> >>> test=> INSERT INTO test VALUES (1);
> >>> INSERT 16392 1
> >>> test=> ALTER TABLE test SET WITHOUT OIDS;
> >>> ALTER TABLE
> >>>
KaiGai Kohei wrote:
> >>CREATE TABLE t (
> >>a int,
> >>b text
> >>) WITH (ROW_LEVEL_ACL=ON);
> >
> > As I mentioned below, this might not be necessary, meaning that row
> > security is enabled for rows where you set the row security value and
> > does not need to be tu
> I am unclear how hard it would be to allow it to be
> controlled via INSERT, meaning it would be present only if the row had a
> SEC value supplied.
It is impossible, and not suitable for SE-PostgreSQL.
The HeapTuple is allocated prior to fetch INSERT'ed value.
In addition, SE-PostgreSQL ass
Bruce Momjian wrote:
KaiGai Kohei wrote:
Let's decide exactly what configure options, GUC options, system catalog
changes, and user-visible SQL command syntax we are going to use for the
patch before you recode anything.
The guest of PGACE security framework should be chosen by configure option
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> Second, system catalogs; are you going to have separate columns for
> >> SQL-level row security and SE-Linux security? If so, is the SE-Linux
> >> column only going to be created by the --enable-selinux build? If so,
> >> th
KaiGai Kohei wrote:
> > Let's decide exactly what configure options, GUC options, system catalog
> > changes, and user-visible SQL command syntax we are going to use for the
> > patch before you recode anything.
>
> The guest of PGACE security framework should be chosen by configure option.
> It a
Bruce Momjian wrote:
Bruce Momjian wrote:
Second, system catalogs; are you going to have separate columns for
SQL-level row security and SE-Linux security? If so, is the SE-Linux
column only going to be created by the --enable-selinux build? If so,
that is going to mean that the /data director
Bruce Momjian wrote:
KaiGai Kohei wrote:
But your larger point is that SQL-row-level security should always be
available, which I just posted about.
If so, it should be hardcoded on somewhere, no need to be implemented
as a guest of PGACE security framework. Its purpose is to implement
enhanced
Bruce Momjian wrote:
> Second, system catalogs; are you going to have separate columns for
> SQL-level row security and SE-Linux security? If so, is the SE-Linux
> column only going to be created by the --enable-selinux build? If so,
> that is going to mean that the /data directory is going to be
KaiGai Kohei wrote:
> > But your larger point is that SQL-row-level security should always be
> > available, which I just posted about.
>
> If so, it should be hardcoded on somewhere, no need to be implemented
> as a guest of PGACE security framework. Its purpose is to implement
> enhanced securit
Bruce Momjian wrote:
Peter Eisentraut wrote:
KaiGai Kohei wrote:
I don't agree. What is the reason why? It has been unclear for me.
The PGACE security framework is designed to allow users to choose
an enhanced security mechanism from some of provided options.
(Currently, we have sepgsql and ro
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
Tom Lane wrote:
KaiGai Kohei <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
I assume that could just be always enabled.
It is not "always" enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security features
Peter Eisentraut wrote:
> KaiGai Kohei wrote:
> > I don't agree. What is the reason why? It has been unclear for me.
> >
> > The PGACE security framework is designed to allow users to choose
> > an enhanced security mechanism from some of provided options.
> > (Currently, we have sepgsql and rowac
KaiGai Kohei wrote:
I don't agree. What is the reason why? It has been unclear for me.
The PGACE security framework is designed to allow users to choose
an enhanced security mechanism from some of provided options.
(Currently, we have sepgsql and rowacl.)
It is quite natural that one is disabled
Greg Stark wrote:
Is there any reason it's easier to do as a configure option instead of
an initdb option or better yet a per-database option?
SE-PostgreSQL needs "libselinux" to communicate with SELinux,
however, it is not available for non-SELinux'ed platforms.
The reason we're shying away f
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> KaiGai Kohei <[EMAIL PROTECTED]> writes:
> >>> Bruce Momjian wrote:
> I assume that could just be always enabled.
> >>> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> >>> rest of enhanced security f
Is there any reason it's easier to do as a configure option instead of
an initdb option or better yet a per-database option?
The reason we're shying away from configure options for functionality
changes is that more and more users are getting pistgres from binary
distributions. Which option
Bruce Momjian wrote:
Tom Lane wrote:
KaiGai Kohei <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
I assume that could just be always enabled.
It is not "always" enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security features (includes the row-level ACL) are
disabled
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> I assume that could just be always enabled.
>
> > It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> > rest of enhanced security features (includes the row-level ACL) are
> > disabled a
Simon Riggs wrote:
>
> On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
> > Tom Lane wrote:
> > > KaiGai Kohei <[EMAIL PROTECTED]> writes:
> > >> Bruce Momjian wrote:
> > >>> I assume that could just be always enabled.
> > >
> > >> It is not "always" enabled. When we build it with SE-Postgr
Simon Riggs wrote:
> On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
> I assume that could just be always enabled.
It is not "always" enabled. When we build it with SE-PostgreSQL feature,
On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
> Tom Lane wrote:
> > KaiGai Kohei <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian wrote:
> >>> I assume that could just be always enabled.
> >
> >> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> >> rest of enhanced
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Bruce Momjian wrote:
>>> I assume that could just be always enabled.
>
>> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
>> rest of enhanced security features (includes the row-level ACL) are
>> disabled automa
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I assume that could just be always enabled.
> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> rest of enhanced security features (includes the row-level ACL) are
> disabled automatically, as we discussed
KaiGai Kohei wrote:
> > I hate to ask for something else from you, but I am trying to figure out
> > how we can proceed in reviewing and applying your additions. I am
> > wondering if you can produce a patch that has the SE-Linux part separate
> > so I can review the non-SE-Linux parts of the patc
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't r
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > KaiGai Kohei wrote:
> I don't oppose to elimination of "--disable-row-acl" options, however,
> it is not clear for me whether it should be unavoidable selection in
> the future, or not.
> >>> Look at the existing configure options; we d
Bruce Momjian wrote:
KaiGai Kohei wrote:
I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't remove features via
configure unless it is f
KaiGai Kohei wrote:
> >> I don't oppose to elimination of "--disable-row-acl" options, however,
> >> it is not clear for me whether it should be unavoidable selection in
> >> the future, or not.
> >
> > Look at the existing configure options; we don't remove features via
> > configure unless it i
I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't remove features via
configure unless it is for some platform-specific reason. Please
1 - 100 of 104 matches
Mail list logo
