Re: LOCK TABLE Permissions

On Fri, Jul 19, 2013 at 12:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> 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);
>
> Perhaps it would be better to refactor with a local variable for the
> aclmask and just one instance of the pg_class_aclcheck call. Also, I'm
> pretty sure that the documentation work needed is more extensive
> than the actual patch ;-). Otherwise, I don't see a problem with this.

I don't really care one way or the other whether we change this in
master, but I think back-patching changes that loosen security
restrictions is a poor idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company