feature.
- Any other idea?
And, I have a question.
Is the new reloption framework designed to store strings?
The latest one support Bool, Int and Real, doen't it?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql
Jaime Casanova wrote:
On Wed, Dec 24, 2008 at 7:05 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
The other need an explanation. A database superuser is allowed
to update system catalog by hand, if it is allowed by the security
policy. For example, he will be able to update relkind in some
the point, it can be fixed with
the above way.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jaime Casanova wrote:
On Wed, Dec 24, 2008 at 6:50 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
The current implementation need to lookup RELOID system cache to
identify the relkind of the relation, because pg_attribtue does
not have any information about relkind. However, I also think
,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Tom Lane wrote:
This seems like a pretty bad idea that will eventually bite you in an
uncomfortable place. Lying about what datatype a field is is just not
safe.
Is it also correct for system attributes?
I don't think the format
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Tom Lane wrote:
This seems like a pretty bad idea that will eventually bite you in an
uncomfortable place. Lying about what datatype a field is is just not
safe.
Is it also correct for system attributes?
I don't think the format
Gregory Stark wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
I didn't replace the previous implementation blindly, I have a few
reasons that the current one is better than previous one.
For example, if an input handler has side-effects, what is happen in
the following query?
SELECT
,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
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:
KaiGai Kohei wrote:
but the auto-creation of pg_security rows does make this problematic.
regproc works because it only supports pre-created pg_proc rows.
Yes, the security label has a different characteristic at the point.
Can we support two data types, one for read
Bruce Momjian wrote:
KaiGai Kohei wrote:
- Two new system columns (security_acl and security_label) are added.
The first one is for the Row-level ACLs, and the other is for the guest
of PGACE security framework which is chosen by user.
This is certainly an impressive patch. I see you
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
- Two new system columns (security_acl and security_label) are added.
The first one is for the Row-level ACLs, and the other is for the guest
of PGACE security framework which is chosen by user
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
Bruce Momjian wrote:
1034 and 25 are the oids for 'acllist' and 'text' and they are being
added to system tables. Are you saying system tables don't use
pg_security but other tables do?
It means users can refer the security_acl
=#
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
| aaa
16384 | 2 | bbb
16384 | 3 | ccc
(3 rows)
DELETE 3
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
I found a strange behavior on the recent v8.4devel with/without
SE-PostgreSQL patch set. Can you reproduce the following behavior?
When I use UPDATE statement with RETURNING clause which contains
references to tableoid system column
not require more than two security system columns, in future also.
Please wait for a few days to see the revised version of patches.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
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
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
think
it's also the underlying reason behind Bruce's complaint here:
As I noted above, I don't oppose to simultaneous support both of
DAC and MAC, if we have *2 security system columns*.
If you can agrre this point, the next patch set will support them
simultaneously.
Thanks,
--
KaiGai Kohei kai
feature is a reasonable option which I can agree.
--
KaiGai Kohei kai...@kaigai.gr.jp
--
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:
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
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:
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
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 allow
what enhanced
security mechanism is available on his system.
In all honesty, I don't understand why the Row-level ACLs has privileged
position in the enhanced securities and it should be always available.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
ignores security
field independent from HEAP_HASSECURITY. When it inserts/update a tuple,
it does not has its security field and lost its security attribute.
It is quite natural.
Does it help you to understand?
---
KaiGai
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.
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
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
,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in userspace, and we can use them as a method to communicate
other processes. (Please imagine copypaste buffer.)
This slide will help your understand:
http://selinux-symposium.org/2007/slides/03-xorg.pdf
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via
that major commercial RDBMSs don't implement it also.)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
they want to use
selinux or row-acls. If their distribution decides not to compile in selinux
support they just have one choice, row-acls (or nothing).
I agree the opinion.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list
KaiGai Kohei wrote:
Gregory Stark wrote:
Peter Eisentraut pete...@gmx.net 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
is necessary, t_infomask
is not set HEAP_HASSECURITY bit, and it does not consume any additional
storage space.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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
Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
opinion, it is not a frequent situation, and it gives us several big
pains, but benefit is smaller than the pains.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
to enable/disable on compile-time.)
Could you wait for a few days to provide newer version.
The following list is the items to be revised:
http://archives.postgresql.org/message-id/4941c690.60...@ak.jp.nec.com
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
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
in pg_control?
In this case, the vanilla PostgreSQL should be simply ignore the
data which is generated by SE-PostgreSQL.
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
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
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
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
at limited number of tables with ROW_LEVEL_ACL=ON.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
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:
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
?
Or, per-table control is not necessary?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 automatically, as we
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,
rest of enhanced security
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
Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
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:
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
Bruce Momjian wrote:
KaiGai Kohei wrote:
I updated the patch set of SE-PostgreSQL (revision 1268).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1268.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1268.patch
[3/6]
http
() at postmaster.c:1283
#15 0x0821d190 in PostmasterMain (argc=1, argv=0x96249e8) at postmaster.c:1031
#16 0x081c20b6 in main (argc=1, argv=0x96249e8) at main.c:188
(gdb)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list
.
- The initial revision of regression test for Row-level ACL is added.
If you have anything to comment for the patches, could you disclose it?
It is not necessary to be a comprehensive one. Don't hesitate to submit.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
If my understanding is correct, the following patch can fix the matters.
!if (ExecContextForcesOids(ps, hasoid)
!hasoid != tupdesc-tdhasoid)
return false;
--- 243,249
!if (ExecContextForcesOids
16424 | 2 | bbb
16425 | 3 | ccc
(6 rows)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
On Mon, 2008-11-24 at 22:09 +0900, KaiGai Kohei wrote:
I removed the two hooks at the r1244 patch set.
As you said, it is fundamentally danger to load uncertain binary modules.
Thus, what we should do is checks on module loading.
The default security policy requires
.
- Code cleanups related to module installation checks.
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
--
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:
KaiGai Kohei wrote:
What I am saying is for the default compile, SQL-level ACLs should be
possible because, since the ACL field has optional storage, there is no
downside to have it be available by default.
I think it is a possible and desirable desicion from the viewpoint
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
However, I think we have a few issues, and it makes unclear whether
we can make an agreement in the community.
The one is a cost of security hooks. They consume a bit more CPU steps
when a security mechanism is enabled. The other
Bruce Momjian wrote:
KaiGai Kohei wrote:
Please consider SELinux/SE-PostgreSQL requires various kind of objects
(including database objects) to be labeled properly at the initial state.
If it allows clients to turn on row-level security feature, it means many
unlabeled tuples appear suddenly
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
Please consider SELinux/SE-PostgreSQL requires various kind of objects
(including database objects) to be labeled properly at the initial state.
If it allows clients to turn on row-level security feature
for the works, and give a lot for inclusion
of the feature at v8.4.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
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:
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
I'll try your approash in first, as follows:
This seems a vast amount of uglification to avoid adding an argument to
CreateTemplateTupleDesc. We do that kind of thing all the time --- it
is a simple and reliable
, when it is remained as
InvalidOid.
Anyway, I've started to work with the prior approach.
Now we have less than two weeks remained in the CommitFest:Nov, so we have
no time to be spent uselessly.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via
Simon Riggs wrote:
On Tue, 2008-11-18 at 16:51 +0900, KaiGai Kohei wrote:
Anyway, I've started to work with the prior approach.
Sounds good.
The matters currently I faces:
* In the approach.1 (add tdhassecurity to TupleDesc)
An explosion of the number of points to be patched
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
I'll try your approash in first, as follows:
This seems a vast amount of uglification to avoid adding an argument to
CreateTemplateTupleDesc. We do that kind of thing all the time --- it
is a simple and reliable change to make.
When
operating systems, I know Trusted Solaris folks have a plan
to implement their facilities on the PGACE security framework, at least.
My 6th patch (rowacl) provides a DAC based row-level security implementation.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED
KaiGai Kohei wrote:
Simon Riggs wrote:
The other is an issue on implementation. Even if row-level security is
disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
has to hold its security context, because it means the security context of
tables, columns, procedure
Simon Riggs wrote:
On Tue, 2008-11-18 at 11:51 +0900, KaiGai Kohei wrote:
Simon Riggs wrote:
The other is an issue on implementation. Even if row-level security is
disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
has to hold its security context, because it means
for the roadmap of SUSE Enterprise
Server
which is a production version of Novell.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
the clients to operate anything on
tuples labeled as sepgsql_table_t except for relabeling them.
(BTW, it is a default type when here is no special configuration.)
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
I could get a help from a native English speaker who works in SELinux community
as a documentation maintainer, so I'm also updating the description now.
If you notice anything, please feel free to comment also.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED
Simon Riggs wrote:
On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
It's unclear for me what is the point you said.
I guess you concern the fixed length field is always allocated in
the case when any security feature is not enabled also, or performance
degradation on the large scale
It shows 8% of degradation in the worst cases, and it has a trend
that larger scale database has smaller degradation.
(The measurement is same as I introduced a month ago.)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql
.
- The wikipage is updated as I promised.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
allows it, but there is no consensus.
At the past, an idea of multiple labels is discussed in SELinux community,
but it was finally dropped because we cannot define the behavior when the
security policy makes different decision for two different labels.
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED
,
--
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
On Sat, 2008-11-08 at 14:21 +0900, KaiGai Kohei wrote:
Some users will be able to take advantage of the facilities without
implementing full MLS. Yet we want the full facilities for Government.
Many people currently run multiple customers in different schemas,
though
Simon Riggs wrote:
On Sat, 2008-11-08 at 18:58 +0900, KaiGai Kohei wrote:
This document gives us some of hints to be considered when we
apply mandatory access control facilities on database systems.
However, it is not a specification of SE-PostgreSQL.
The series of documents assumes
control facilities on database systems.
However, it is not a specification of SE-PostgreSQL.
The series of documents assumes traditional multi-level-security
system, so it does not care about flexible policy, type-enforcement
rules and collaborating with operating system.
Thanks,
--
KaiGai Kohei
the patches?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
KaiGai Kohei wrote:
KaiGai Kohei wrote:
Simon Riggs wrote:
On Tue, 2008-10-21 at 18:48 +0900, KaiGai Kohei wrote:
I started to rework the SE-PostgreSQL documentation to catch up
the latest implementation, because the existing PDF documents are
a bit legacy to be updated.
In addition, I
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Wouldn't this omit comparing the null bitmap?
Oops, I added the comparison of null bitmap here.
That's really, really ugly code. Why would it be necessary anyway?
Shouldn't the security tag be expected to match
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
However, I wonder if the oid field should be also preserved at same
place, not inside a specific trigger function.
Possibly. I wasn't planning to mess with it now; but if you've fixed
the other problems with assigning to a system
comment?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
*** base/src/backend/utils/adt/trigfuncs.c.orig 2008-11-06 10:24:39.0 +0900
--- base/src/backend/utils/adt/trigfuncs.c 2008-11-06 10:29:41.0 +0900
***
*** 69,77
* another OID value into newtuple. (That's
Andrew Dunstan wrote:
KaiGai Kohei wrote:
*** 80,88
HeapTupleHeaderGetNatts(oldheader))
((newheader-t_infomask ~HEAP_XACT_MASK) ==
(oldheader-t_infomask ~HEAP_XACT_MASK))
! memcmp(((char *)newheader) + offsetof(HeapTupleHeaderData,
t_bits
Bruce Momjian wrote:
KaiGai Kohei wrote:
I've updated my patches, it contains a few bugfixes.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
[3/6]
http
Bruce Momjian wrote:
KaiGai Kohei wrote:
I just looked over the patch. This new version with row-level SQL
security has certainly reduced the SE-Linux-specific part, which is
good.
It was interesting how you implemented SQL-level column-level
permissions:
CREATE TABLE customer
of patches are unchanged from
the previous vesion. If you can comment anything, I can fix them without
waiting for the final commit fest.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
.
Do you have any updated one?
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
vesion. If you can comment anything, I can fix them without
waiting for the final commit fest.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Simon Riggs wrote:
On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:
I've updated my patches, these are ready for CommitFest:Nov.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump
KaiGai Kohei wrote:
Simon Riggs wrote:
On Tue, 2008-10-21 at 18:48 +0900, KaiGai Kohei wrote:
I started to rework the SE-PostgreSQL documentation to catch up
the latest implementation, because the existing PDF documents are
a bit legacy to be updated.
In addition, I moved them to wiki site
701 - 800 of 907 matches
Mail list logo
