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
