[HACKERS] LOCK TABLE Permissions

[Stephen Frost]

Greetings,

  We've run into a curious case and I'd like to solicit feedback
  regarding a possible change to the access rights required to acquire
  locks on a relation.  Specifically, we have a process which normally
  INSERTs into a table and another process which Exclusive locks that
  same table in order to syncronize other processing.  We then ran into
  a case where we didn't actually want to INSERT but still wanted to
  have the syncronization happen.  Unfortunately, we don't allow
  LOCK TABLE to acquire RowExclusive unless you have UPDATE, DELETE, or
  TRUNCATE privileges.

  My first impression is that the current code was just overly
  simplistic regarding what level of permissions are required for a
  given lock type and that it wasn't intentional to deny processes which
  have INSERT privileges from acquiring RowExclusive (as they can do so
  anyway using an actual INSERT).  Therefore, I'd like to propose the
  below simple 3-line patch to correct this.

  Thoughts?  Objections to back-patching?

        Thanks,

                Stephen

diff --git a/src/backend/commands/lockcmds.c b/src/backend/commands/lockcmds.c
new file mode 100644
index 49950d7..60f54c5 100644
*** a/src/backend/commands/lockcmds.c
--- b/src/backend/commands/lockcmds.c
*************** LockTableAclCheck(Oid reloid, LOCKMODE l
*** 174,179 ****
--- 174,182 ----
    if (lockmode == AccessShareLock)
        aclresult = pg_class_aclcheck(reloid, GetUserId(),
                                      ACL_SELECT);
+   else if (lockmode == RowExclusiveLock)
+       aclresult = pg_class_aclcheck(reloid, GetUserId(),
+                        ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE);
    else
        aclresult = pg_class_aclcheck(reloid, GetUserId(),
                                      ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE);

signature.asc
Description: Digital signature