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

Reply via email to