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 possib
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 re
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
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 othe
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
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 ove
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
> sec
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
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 mean
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 mea
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:
> >> 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 g
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 fo
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
befo
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.
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 cer
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
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 th
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 cha
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
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
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.
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, y
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
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. :(
*
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.
> >
> >
>>> 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 consi
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 i
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 poin
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, becaus
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,
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 securi
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, proc
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.
>>
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_cla
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
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
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 larg
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 inc
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, a
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
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 ass
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,
>>
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 multi-lev
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 Tab
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 le
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 h
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
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
>>>
>>>
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
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 an
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
O
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
> 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
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 Ta
> 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 tri
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 j
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.patc
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]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4
59 matches
Mail list logo
