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:
Sorry I see the comment. I'll continue the work to fulfill the comment.
2009/3/17 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
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
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.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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 individually at
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
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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}
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Alvaro Herrera alvhe...@commandprompt.com 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?
Ron Mayer wrote:
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
KaiGai Kohei wrote:
* [..feature description..]
This again falls into the category of trying to have more fine-grained
permissions than vanilla PostgreSQL has
* 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
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
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
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
20 matches
Mail list logo
