KaiGai Kohei wrote:
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
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 loadable modules to be
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
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 is
On Fri, 2008-11-21 at 19:47 +0900, KaiGai Kohei wrote:
In the result of pgbench -i -s 10, the sepostgresql_row_level=true
case consumed 152MB of storage, and the sepostgresql_row_level=false
case consumed 148MB of storage.
Sounds good. It may not sound much to you, but it is all good news.
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 of
security
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 is prevention to override
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.
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, it means many
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, it
Bruce Momjian wrote:
However, the toggle of row-level security feature should be controled
via a GUC option, not a discretionary option.
I'll add a sepostgresql_row_level option defined as bool to control
it on start up time.
This sounds similar to BSD capability were certain security
Bruce Momjian wrote:
Bruce Momjian wrote:
However, the toggle of row-level security feature should be controled
via a GUC option, not a discretionary option.
I'll add a sepostgresql_row_level option defined as bool to control
it on start up time.
This sounds similar to BSD capability were
KaiGai Kohei wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
However, the toggle of row-level security feature should be controled
via a GUC option, not a discretionary option.
I'll add a sepostgresql_row_level option defined as bool to control
it on start up time.
This sounds
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. In generally, these have to be labeled
KaiGai Kohei [EMAIL PROTECTED] writes:
It is unclear for me when the CommtiFest:Nov is finished, but it is sure
we don't have enough days.
This commitfest goes until it's done. I knew at the beginning that we'd
not be done at the end of November. The original schedule allowed two
months for
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. In generally,
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.
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
KaiGai Kohei wrote:
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
The length of HeapTupleData is determined during heap_form_tuple(),
and it is unchanged later. Thus, we have to interpose here, as object
identifier doing.
Currently yes. Is there a reason not to? Do we rely on the tuple length
staying same after those operations?
Just considering multiple
On Tue, 2008-11-18 at 16:51 +0900, KaiGai Kohei wrote:
Anyway, I've started to work with the prior approach.
Sounds good.
Now we have less than two weeks remained in the CommitFest:Nov, so we have
no time to be spent uselessly.
SUSE?
The u might be a large-letter.
Sorry, I wasn't
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. :(
* In the
On Tue, 2008-11-18 at 21:40 +0900, KaiGai Kohei wrote:
A concern is why you suggested this feature at the last half of the
November. :(
I gave you my feedback as soon as I read the Wiki article. Even then I
didn't understand some aspects of the patch design, which was
unfortunate. But these
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 designing a patch, you
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
On Wed, 2008-11-19 at 01:42 +0900, KaiGai Kohei wrote:
Simon,
I'm sorry, if my expression felt you uncomfortable.
No worries at all. I know exactly how you feel. Good Luck.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers
On Sun, 2008-11-16 at 01:40 +0900, KaiGai Kohei wrote:
I had two reasons why I didn't implement the option.
The first is the relationship between table/column-level access controls
and row-level controls on system catalogs is unclear.
For example, SE-PostgreSQL handles DELETE on pg_class
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 and largeobjects.
However,
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 and
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 the security
On Tue, 2008-11-18 at 13:10 +0900, KaiGai Kohei wrote:
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
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 the
On Tue, 2008-11-18 at 15:02 +0900, KaiGai Kohei wrote:
If we focus on the CreateTemplateTupleDesc(), 5 of call points give
possibile hasoid argument, and rest of them always give false.
I guess it will be same in the security context cases.
However, we have to change all the call points when
Simon Riggs wrote:
Another way would be to include a security context in all newly
created
tuples, but remove it during heap_update, heap_insert etc if it is
unused by the relation. That seems more straightforward.
It is not a reasonable option.
The length of HeapTupleData is determined
Simon Riggs wrote:
I would also like to see the feature part of normal Postgres, rather
than as a compile time option. The per-row overhead would then be
optional, just as WITH OIDS is optional. This would allow many
applications to take advantage of row level security, without the need
for
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 databases.
If
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
On Sat, 2008-11-15 at 00:58 +0900, KaiGai Kohei wrote:
Sorry, it seems to me you misunderstand something.
Yep, seems so. Thank goodness for that. Thanks for putting me straight.
I would also like to see the feature part of normal Postgres, rather
than as a compile time option. The per-row
On Fri, 2008-11-07 at 16:52 -0500, Bruce Momjian wrote:
Simon, would you read the chapter on covert channels? You might
understand it better than I do and it might give you some ideas:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950
OK, read that now.
Looks to me
Simon Riggs wrote:
The only remaining problem for me now is the size of the security
context column added to each row. I can accept a fixed length 4 byte
value, but anything longer just seems that it will render this unusable.
Normal apps should be able to benefit from row level security, as
Simon Riggs wrote:
On Fri, 2008-11-07 at 15:12 -0500, Robert Haas wrote:
Foreign Key deletions could be handled correctly if you treat them as
updates. If we have the following example
TableA
security_context=y value=2 fk=1
TableB
security_context=x value=1
TableA refers to TableB.
Simon, Thanks for your comments.
Some initial thoughts based upon reading the Wiki. I've not been
involved in things up to now, so if this dredges up old discussions,
well, these are my thoughts.
I want SEPostgreSQL, but I'd like it to work without needing to be a
compile time option so
On Fri, 2008-11-07 at 16:52 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
So if somebody with context x tries to delete value1 from TableB, they
will be refused because of a row they cannot see. In this case the
correct action is to update the tuple in TableB so it now has a
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 this would let them
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 traditional
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 this
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
Simon Riggs wrote:
On Fri, 2008-11-07 at 16:52 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
So if somebody with context x tries to delete value1 from TableB, they
will be refused because of a row they cannot see. In this case the
correct action is to update the tuple in TableB so it now has
I updated the patch set of SE-PostgreSQL (revision 1197).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1197.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1197.patch
[3/6]
On Fri, 2008-11-07 at 18:20 +0900, KaiGai Kohei wrote:
I updated the patch set of SE-PostgreSQL (revision 1197).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1197.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1197.patch
Simon Riggs wrote:
Some initial thoughts based upon reading the Wiki. I've not been
involved in things up to now, so if this dredges up old discussions,
well, these are my thoughts.
I want SEPostgreSQL, but I'd like it to work without needing to be a
compile time option so people can just
Foreign Key deletions could be handled correctly if you treat them as
updates. If we have the following example
TableA
security_context=y value=2 fk=1
TableB
security_context=x value=1
TableA refers to TableB. Context x cannot see context y.
So if somebody with context x tries to
On Fri, 2008-11-07 at 15:12 -0500, Robert Haas wrote:
Foreign Key deletions could be handled correctly if you treat them as
updates. If we have the following example
TableA
security_context=y value=2 fk=1
TableB
security_context=x value=1
TableA refers to TableB. Context x
The low-privilege user isn't elevating the label. If the tuple was
visible by multiple labels it was already elevated. All I am suggesting
is the system remove the one it can see, leaving the other ones intact.
This makes the row appear to be deleted by the lower privileged user,
whereas in
On Fri, Nov 07, 2008 at 01:50:18PM +, Simon Riggs wrote:
How will unique indexes work? Do you implicitly add security context as
last column on every unique index, or does the uniqueness violation only
occurs within security contexts, or does the uniqueness violation tested
against all
Simon Riggs [EMAIL PROTECTED] writes:
Any system with more than 32,000 security contexts is going to be
unmanageable and probably therefore insecure...
Perhaps, but it's doubtful that such a restriction will actually save
any space after you consider the alignment behavior. I'd go with an
Oid.
Simon Riggs wrote:
So if somebody with context x tries to delete value1 from TableB, they
will be refused because of a row they cannot see. In this case the
correct action is to update the tuple in TableB so it now has a
security_context = y. The user with x cannot see it and can be
On Fri, 2008-11-07 at 13:19 -0500, Bruce Momjian wrote:
The security context on each row could be an optional column present
only if HEAP_HASSECURITYCONTEXT is set (0x0010 see htup.h), just
like
OIDs. Use a specific datatype rather than TEXT. That datatype could
be
an identifier to
59 matches
Mail list logo
