Re: Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))
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://archives.postgresql.org/message-id/49b51791.5080...@enterprisedb.com I'd like to push this to pgFoundry first and then work again together with Sync.Rep and Hot Standby for 8.5. Great! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))
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 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://archives.postgresql.org/message-id/49b51791.5080...@enterprisedb.com I'd like to push this to pgFoundry first and then work again together with Sync.Rep and Hot Standby for 8.5. Great! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- -- Koichi Suzuki - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))
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. Agreed. At some point we just have to wrap up and cut the release. Tweaking indefinitely is not fair to all those patches that have already been pushed back, nor to those that have already been committed and are waiting to be released as part of 8.4. Apart from SE-PostgreSQL, we have four remaining items on the commitfest page: GIN fast insert I agree with Tom that we should just disable regular index scans for GIN. If someone misses it in 8.4, we can try to find a way to do it safely in 8.5. Removing existing capability is a bit worrisome, but I'm even less happy with the out of memory condition in this patch and in the partial match patch that has been committed already. That really needs to be cleaned up. B-Tree emulation for GIN I think this is in pretty good shape. 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. Proposal of PITR performance improvement Hmm. The first version of this was submitted back in October, as an external tool. There's still some outstanding issues: http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php. I think we should push this to 8.5, for the same reasons as SE-PostgreSQL. On the positive side, the external tool is on pgFoundry for use with 8.4 (and earlier releases too?). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))
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 to do. I'll take this up next. AFAIR refactoring to put that which should be in the planner into the planner was the only significant issue. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))
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 with Sync.Rep and Hot Standby for 8.5. 2009/3/16 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: 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. Agreed. At some point we just have to wrap up and cut the release. Tweaking indefinitely is not fair to all those patches that have already been pushed back, nor to those that have already been committed and are waiting to be released as part of 8.4. Apart from SE-PostgreSQL, we have four remaining items on the commitfest page: GIN fast insert I agree with Tom that we should just disable regular index scans for GIN. If someone misses it in 8.4, we can try to find a way to do it safely in 8.5. Removing existing capability is a bit worrisome, but I'm even less happy with the out of memory condition in this patch and in the partial match patch that has been committed already. That really needs to be cleaned up. B-Tree emulation for GIN I think this is in pretty good shape. 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. Proposal of PITR performance improvement Hmm. The first version of this was submitted back in October, as an external tool. There's still some outstanding issues: http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php. I think we should push this to 8.5, for the same reasons as SE-PostgreSQL. On the positive side, the external tool is on pgFoundry for use with 8.4 (and earlier releases too?). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- -- Koichi Suzuki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 a later date? I think that makes sense. Implement just a very basic core in a first patch, and start adding checks slowly, one patch each. We have talked about incremental patches in the past. We wouldn't get unbreakable PostgreSQL in a single commit, but we would at least start moving. The good thing about having started in the opposite direction is that by now we know that the foundation APIs are good enough to build the complete feature. 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. KaiGai-san, the only option I can offer is perhaps to list a URL for your SE-PostgreSQL patch to be applied by people who want to use SE-PG. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 individually at a later date? I think that makes sense. Implement just a very basic core in a first patch, and start adding checks slowly, one patch each. We have talked about incremental patches in the past. We wouldn't get unbreakable PostgreSQL in a single commit, but we would at least start moving. The good thing about having started in the opposite direction is that by now we know that the foundation APIs are good enough to build the complete feature. 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. KaiGai-san, the only option I can offer is perhaps to list a URL for your SE-PostgreSQL patch to be applied by people who want to use SE-PG. Needless to say, I'm dissatisfied with this offer. But I can understand we're paying effort to release the v8.4 on schedule as far as possible, and we don't have infinite time for development all the items. Yes, it is possible to accept the offer for me. Meanwhile, I would not like to repeat same thing in the v8.5 development cycle again. At the head of this year, we have rest of three big new features (Sync-replication, Hot-standby and SE-PostgreSQL) but all of them have been bursted for the v8.4. In the v8.5 development cycle, I'll pay effort to propose this feature with smaller part, to build it up step-by-step, as suggested in this commit fest. So, I would like folks to review and commit it in the earlier phase. What is your opinion? Currently, we have the following action items for the SE-PostgreSQL with full-functionalities. I'll consider what components can be implemented as a separated patch again, and submit them at: http://wiki.postgresql.org/wiki/CommitFest_2009-First 0. Changes in security policy. - I got a few requirements for the SELinux security policy. It is necessary to discuss in the SELinux community also. - *:{select} and *:{use} permission should be integrated - db_database:{get_param set_param} to be removed - A new db_database:{superuser} permission 1. Security system columns support It contains a few sub-facilities, and they can be submitted in the different patches. 1-1. security system columns and pg_security system catalog 1-2. writable system columns support(security_label and security_acl) 1-3. reclaim unused entries in pg_security system catalog 2. Basic tables/columns-level access controls (dependency: 1-1) It means the facility proposed in the v8.4 development. We also need to discuss an issue of ACL_UPDATE/ACL_SELECT_FOR_UPDATE. 3. Row-level access control facilities (dependency: 1-2, 2) It also provides permission checks in row-level granularity both of DAC and MAC. 4. Advanced permission support (dependency: 2) 4-1. db_procedure:{install} permission. Heikki also required similar stuff in the vanilla PostgreSQL. 4-2. db_database:{load_module install_module} permission. 4-3. file:{read write} permission for COPY TO/FROM and others. 4-4. permission checks on the large objects. (I guess vanilla PostgreSQL also requires it.) 5. Audit support (dependency: 2) It is not a facility proposed in the v8.4. SE-PostgreSQL enables to generate audit records for violated accesses. This facility write them out to system audit daemon. 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
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 db_table:{lock} permission. This again falls into the category of trying to have more fine-grained permissions than vanilla PostgreSQL has. Just give up on the lock permission, and let it check update permission instead. Yes, it can be annoying that you need update-permission to do SELECT FOR SHARE, but that's an existing problem and not in scope for this patch. 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 a later date? I think that makes sense. Implement just a very basic core in a first patch, and start adding checks slowly, one patch each. We have talked about incremental patches in the past. We wouldn't get unbreakable PostgreSQL in a single commit, but we would at least start moving. The good thing about having started in the opposite direction is that by now we know that the foundation APIs are good enough to build the complete feature. What should I do for this matter? At least, it is necessary to decide when we should fix it. v8.4? v8.5? If we fix it soon, what strategy is desirable? 1) Add a new GRANT privilege something like LOCK. It is straight forward approach, but contains user visible change. In MySQL, it has an individual privilege for explicit table locks. 2) Shrink ACL_SELECT_FOR_UPDATE to ACL_UPDATE in runtime. It is invisible from users, but GRANT UPDATE still contains a meaning of explicit table locks. 3) GRANT UPDATE ... also allows users ACL_SELECT_FOR_UPDATE, not only ACL_UPDATE. It is similar to 2) option, but it also modifies ACL side, not the requiredPerms side. 4) Other strategy? 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
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 vanilla PostgreSQL has. Just give up on the lock permission, and let it check update permission instead. Yes, it can be annoying that you need update-permission to do SELECT FOR SHARE, but that's an existing problem and not in scope for this patch. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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-grained permissions than vanilla PostgreSQL has. Just give up on the lock permission, and let it check update permission instead. Yes, it can be annoying that you need update-permission to do SELECT FOR SHARE, but that's an existing problem and not in scope for this patch. Can I consider the term of problem means it can be resolved in the future (v8.5, if possible) version? -- 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
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 trying to have more fine-grained permissions than vanilla PostgreSQL has. Just give up on the lock permission, and let it check update permission instead. Yes, it can be annoying that you need update-permission to do SELECT FOR SHARE, but that's an existing problem and not in scope for this patch. Can I consider the term of problem means it can be resolved in the future (v8.5, if possible) version? Sure, a patch to address that in 8.5 would be welcome. I don't know why it's like that. Maybe no-one has just bothered. Or maybe it's because of backwards-compatibility or SQL standard compliance. In any case, it would seem useful to separate them in the future. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 category of trying to have more fine-grained permissions than vanilla PostgreSQL has. Just give up on the lock permission, and let it check update permission instead. Yes, it can be annoying that you need update-permission to do SELECT FOR SHARE, but that's an existing problem and not in scope for this patch. 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 a later date? That might relieve critics of the sneaking suspicion that there may be some semantic change that hasn't been identified and discussed and snuck through? Some of them are probably good ideas but if they are they're probably good ideas even for non-SE semantics too. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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} permission. This again falls into the category of trying to have more fine-grained permissions than vanilla PostgreSQL has. Just give up on the lock permission, and let it check update permission instead. Yes, it can be annoying that you need update-permission to do SELECT FOR SHARE, but that's an existing problem and not in scope for this patch. 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 a later date? I think that makes sense. Implement just a very basic core in a first patch, and start adding checks slowly, one patch each. We have talked about incremental patches in the past. We wouldn't get unbreakable PostgreSQL in a single commit, but we would at least start moving. The good thing about having started in the opposite direction is that by now we know that the foundation APIs are good enough to build the complete feature. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 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 a later date? I think that makes sense. Implement just a very basic core in a first patch, and start adding checks slowly, one patch each. We have talked about incremental patches in the past. +1 from an end-user's point of view too. I'm quite aware of the postgres privileges, and if there were a MAC system of enforcing those I'd be reasonably likely to enable them right away. On the other hand, if SEPostgres initially comes with a different set of privileges that don't map to what I'm already using, I'm much less likely to spend the time to figure out the two different systems. And I do see row-level restrictions (and the other access restrictions mentioned in this thread) as quite orthogonal to MAC vs DAC. Would it be cool to have row-level permissions in postgres? Sure, as an abstract concept. Do I have any use for them? Seeing that I'm getting by without them, the answer must be not now. We wouldn't get unbreakable PostgreSQL in a single commit, but we would at least start moving. The good thing about having started in the opposite direction is that by now we know that the foundation APIs are good enough to build the complete feature. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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? Then discuss any other parts individually at a later date? I think that makes sense. That's pretty much the advice we gave KaiGai-san in January ... which I gather he hasn't taken. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 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 a later date? I think that makes sense. Implement just a very basic core in a first patch, and start adding checks slowly, one patch each. We have talked about incremental patches in the past. +1 from an end-user's point of view too. I'm quite aware of the postgres privileges, and if there were a MAC system of enforcing those I'd be reasonably likely to enable them right away. On the other hand, if SEPostgres initially comes with a different set of privileges that don't map to what I'm already using, I'm much less likely to spend the time to figure out the two different systems. I cannot update whole of the wikipage yet, but updated some of descriptions in object classes and permission. http://wiki.postgresql.org/wiki/SEPostgreSQL#Object_classes_and_permission Some of permissions are mapped to the vanilla PostgreSQL privileges, and some of them are not so. * 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 db_table:{select} and db_column:{select} for all the target columns are checked. But it applies db_table:{lock} on LockTableCommand(). * ACL_UPDATE The db_table:{update} and db_column:{update} for all the target columns are checked. * ACL_DELETE The db_table:{delete} is also checked. No column-level checks here. * ACL_TRUNCATE The db_table:{delete} is also checked. SE-PostgreSQL does not discriminate between TRUNCATE and DELETE. * ACL_REFERENCES * ACL_TRIGGER SE-PostgreSQL does not care about these privileges. But, it checks db_procedure:{execute} on trigger invocation time, and it also checks db_table:{select} on checks of FK constraint within its secondary SQL execution. * ACL_EXECUTE The db_procedure:{execute} is also checked. This check is embedded within pg_proc_ackcheck(). * ACL_USAGE * ACL_CREATE * ACL_CREATE_TEMP SE-PostgreSQL does not care about there privileges. * ACL_CONNECT The db_database:{access} is also checked. This check is embedded within pg_database_aclcheck(). * ACL_SELECT_FOR_UPDATE The db_table:{lock} should be also checked, but ... * database superuser privilege The db_database:{superuser} newly added should be also checked. In addition, SE-PostgreSQL defines and users some of new privileges. * db_xxx:{relabelfrom} and db_xxx:{relabelto} It is checked when the security context of database objects are changed. * db_xxx:{create} It is typically checked when CREATE TABLE and others. SE-PostgreSQL assigns a default security context on the table and columns newly created, if user does not give any security context explicitly. Then, it checks whether the user have db_xxx:{create} privileges on the tables/columns/etc labeled as the security context, or not. * db_xxx:{setattr} * db_xxx:{drop} It is typically cheched when ALTER/DROP TABLE and others. The vanilla PostgreSQL checks user's privileges based on the ownership, but SE-PostgreSQL does not consider the concept of owner due to its MAC policy. These permission are checked based on the security context assigned to the target objects. * db_procedure:{entrypoint} SE-PostgreSQL allows client to change its privilege during execution of certain procedures (called as trusted procedure). It checks this permission when user tries to invoke trusted procedure. The vanilla PostgreSQL does not have similar ACL, but it concept it similar to security definer or setuid on operating system. And I do see row-level restrictions (and the other access restrictions mentioned in this thread) as quite orthogonal to MAC vs DAC. Would it be cool to have row-level permissions in postgres? Sure, as an abstract concept. Do I have any use for them? Seeing that I'm getting by without them, the answer must be not now. We defined six permissions for row-level, but not used (included) now. * db_tuple:{relabelfrom} * db_tuple:{relabelto} * db_tuple:{select} * db_tuple:{update} * db_tuple:{insert} * db_tuple:{delete} As SE-PostgreSQL doing on any other database object, it (can) assigns a default security context on the tuple newly inserted, if user does not given any security context explicitly. Then, it checks db_tuple:{insert} permission on them. Do you need explanation for any other permissions on db_tuple
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
* 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 db_table:{select} and db_column:{select} for all the target columns are checked. But it applies db_table:{lock} on LockTableCommand(). * ACL_UPDATE The db_table:{update} and db_column:{update} for all the target columns are checked. * ACL_DELETE The db_table:{delete} is also checked. No column-level checks here. I'm more or less with you up to this point. * ACL_TRUNCATE The db_table:{delete} is also checked. SE-PostgreSQL does not discriminate between TRUNCATE and DELETE. But this seems wrong. * ACL_REFERENCES * ACL_TRIGGER SE-PostgreSQL does not care about these privileges. But, it checks db_procedure:{execute} on trigger invocation time, and it also checks db_table:{select} on checks of FK constraint within its secondary SQL execution. And so do these. Why should there be any asymmetry with regular PostgreSQL here? * ACL_EXECUTE The db_procedure:{execute} is also checked. This check is embedded within pg_proc_ackcheck(). Good... * ACL_USAGE * ACL_CREATE * ACL_CREATE_TEMP SE-PostgreSQL does not care about there privileges. Again, there doesn't seem to be any reason for this asymmetry. I think you should change it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 The db_table:{select} and db_column:{select} for all the target columns are checked. But it applies db_table:{lock} on LockTableCommand(). * ACL_UPDATE The db_table:{update} and db_column:{update} for all the target columns are checked. * ACL_DELETE The db_table:{delete} is also checked. No column-level checks here. I'm more or less with you up to this point. * ACL_TRUNCATE The db_table:{delete} is also checked. SE-PostgreSQL does not discriminate between TRUNCATE and DELETE. But this seems wrong. We consider these differences are just only the way to remove all the tuples, not the target of the tables and its result. * ACL_REFERENCES * ACL_TRIGGER SE-PostgreSQL does not care about these privileges. But, it checks db_procedure:{execute} on trigger invocation time, and it also checks db_table:{select} on checks of FK constraint within its secondary SQL execution. And so do these. Why should there be any asymmetry with regular PostgreSQL here? The ACL_REFERENCES is checked when we set up FK constraint, then ri_PerformCheck() invokes another query to check constraint with privileges of the table owner. It assumes the owner can access on the table owned. However, SE-PostgreSQL works orthogonally to the ownership. We don't assume the client can access on the FK constrainted table, and it apply appropriate checks on the secondary query also, so it does not need to check on FK creation time. The ACL_TRIGGER is also checked when CREATE TRIGGER. If someone set a trigger function which is not allowed to execute from other persons, the other person can invoke this function via trigger mechanism. I wonder why the vanilla PostgreSQL does not put pg_proc_aclcheck() on the ExecCallTriggerFunc(). * ACL_EXECUTE The db_procedure:{execute} is also checked. This check is embedded within pg_proc_ackcheck(). Good... * ACL_USAGE * ACL_CREATE * ACL_CREATE_TEMP SE-PostgreSQL does not care about there privileges. Again, there doesn't seem to be any reason for this asymmetry. I think you should change it. The ACL_CREATE and ACL_CREATE_TEMP are checked on namespace in which the object newly created belongs. And the ACL_USAGE is checked on various kind of database objects, but they don't have its security context. Funfamentally, SELinux requires to check user's privileges on the object newly created. The object is labeled as a default security context (if user does not specify anything) on its creation. So, if we implement it now, a facility is necessary to store a security context of namespace and others. 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
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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 someone without ACL_EXECUTE to invoke the functions, but I cannot believe ACL_TRIGGER implicitly contains such a meaning. Indeed, I put a hook to check db_procedure:{execute} permission in SELinux, but putting pg_proc_aclcheck() here is meaningful not only SE-PostgreSQL users. I found another matter related to triggers. I'll report it on another messages. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com *** src/backend/commands/trigger.c (revision 1704) --- src/backend/commands/trigger.c (working copy) *** *** 1560,1566 --- 1560,1576 * call. */ if (finfo-fn_oid == InvalidOid) + { + AclResult aclresult; + + aclresult = pg_proc_aclcheck(trigdata-tg_trigger-tgfoid, + GetUserId(), ACL_EXECUTE); + if (aclresult != ACLCHECK_OK) + aclcheck_error(aclresult, ACL_KIND_PROC, + get_func_name(trigdata-tg_trigger-tgfoid)); + fmgr_info(trigdata-tg_trigger-tgfoid, finfo); + } Assert(finfo-fn_oid == trigdata-tg_trigger-tgfoid); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710)
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/sepgsql-docs-8.4devel-r1710.patch http://sepgsql.googlecode.com/files/sepgsql-tests-8.4devel-r1710.patch - List of updates: * Permission checks on SET/SHOW were removed. * Add a new permission: db_database:{superuser} sepgsqlCheckDatabaseSuperuser() is invoked from superuser_arg() to check whether the clietn can perform as a superuser in this database, or not. * Permission checks on procedure installation is separated. * Permission checks on install/load C-libraries are separated. * Read file checks on pg_read_file() is added. - Scale of patches: * r1710 (the latest revision) 60 files changed, 3686 insertions(+), 10 deletions(-), 4952 modifications(!) * r1704 (previous revision) 60 files changed, 4048 insertions(+), 11 deletions(-), 4944 modifications(!) ... about 300 lines were downsized. - Remaining issue: * 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. 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