Sorry I see the comment. I'll continue the work to fulfill the comment.
2009/3/17 Heikki Linnakangas :
> Koichi Suzuki wrote:
>>
>> I believe all the issues pointed out in
>> http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
>> been covered in the current patch, as discussed
Koichi Suzuki wrote:
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the current patch, as discussed with Simon. I also
understand that we're running out of time.
I pointed out a few more issues here:
http://archive
Hi,
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the current patch, as discussed with Simon. I also
understand that we're running out of time.
I'd like to push this to pgFoundry first and then work again together
wi
Heikki Linnakangas writes:
> Improve Performance of Multi-Batch Hash Join for Skewed Data Sets
> I believe everyone's happy with the performance testing that's been
> done. Some of the logic ought to be moved to the planner, and maybe
> there's some other cleanup to do.
I'll take this up next.
Bruce Momjian wrote:
Well, we have been trying to go simplify the SE-PostgreSQL patch since
September, and while we have made progress, we still have work to do,
and at this point I think we have run out of time. I think we have
given it a fair shot, but I don't think it is going to make 8.4.
Bruce Momjian wrote:
Alvaro Herrera wrote:
Would it make sense to instead of removing and deferring pieces bit by bit to
instead work the other way around? Extract just the part of the patch that
maps SELinux capabilities to Postgres privileges as a first patch? Then
discuss any other parts indi
Alvaro Herrera wrote:
> > Would it make sense to instead of removing and deferring pieces bit by bit
> > to
> > instead work the other way around? Extract just the part of the patch that
> > maps SELinux capabilities to Postgres privileges as a first patch? Then
> > discuss any other parts individ
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas writes:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again fall
KaiGai Kohei wrote:
I wonder why the vanilla PostgreSQL does not put pg_proc_aclcheck()
on the ExecCallTriggerFunc().
I don't think we can assume any trigger functions are "trusted",
because normal users with ACL_TRIGGER privilege can set their
procedures on the allowed tables.
It also means so
Robert Haas wrote:
* ACL_INSERT
The db_table:{insert} and db_column:{insert} for all the target
columns are checked. The table-level permission does not override
column-level permission, so the client need to have privileges
for both of objects. It is same as other permissions.
* ACL_SELECT
> * ACL_INSERT
> The db_table:{insert} and db_column:{insert} for all the target
> columns are checked. The table-level permission does not override
> column-level permission, so the client need to have privileges
> for both of objects. It is same as other permissions.
>
> * ACL_SELECT
> The d
Ron Mayer wrote:
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas writes:
KaiGai Kohei wrote:
* [..feature description..]
This again falls into the category of trying to have more fine-grained
permissions than vanilla PostgreSQL has
Would it make sense to instead of r
Alvaro Herrera writes:
> Gregory Stark escribió:
>> Would it make sense to instead of removing and deferring pieces bit by bit to
>> instead work the other way around? Extract just the part of the patch that
>> maps SELinux capabilities to Postgres privileges as a first patch? Then
>> discuss any
Alvaro Herrera wrote:
> Gregory Stark escribió:
>> Heikki Linnakangas writes:
>>
>>> KaiGai Kohei wrote:
* [..feature description..]
>>> This again falls into the category of trying to have more fine-grained
>>> permissions than vanilla PostgreSQL has
>> Would it make sense to instead of
Gregory Stark escribió:
> Heikki Linnakangas writes:
>
> > KaiGai Kohei wrote:
> >> * ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
> >>checks db_table:{update} permission on SELECT ... FOR SHARE OF,
> >>instead of db_table:{lock} permission.
> >
> > This again f
Heikki Linnakangas writes:
> KaiGai Kohei wrote:
>> * ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
>>checks db_table:{update} permission on SELECT ... FOR SHARE OF,
>>instead of db_table:{lock} permission.
>
> This again falls into the category of trying to have
KaiGai Kohei wrote:
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so
SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of tryin
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of trying to have more fine-gr
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of trying to have more fine-grained
permissions than van
Heikki, it is the list of updated patches:
http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1710.patch
http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1710.patch
http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1710.patch
http://sepgsql.googlecode.com/files/sepgs
20 matches
Mail list logo
