Horton

Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE

Karel Zak <zakkr@zf.jcu.cz>

View thread
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2000-03-01T15:44:49Z
Lists: pgsql-hackers 
> I would like to take a look at SQL3 first, because they define some more
> privilege stuff which we could take into account (ROLES, for example).

 Yes. Just today I look at Oracle's documentation for ROLEs, PROFILEs
... my idea is prepare acl/account code for this freatures too. What?

IMHO this discussion good adept for any new-acl&accout project. Agree?

> By the way: Regarding your original patch that disallowed LOCK to users, I

  ... and I see your web page, you listen good music :-)

> looked it up in the source and it turns out that in order to lock a table
> you need write access to it. Isn't that sufficient?

 You mean this original PG's code (?):

    if (lockstmt->mode == AccessShareLock)
                aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL
    else
                aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL

    if (aclresult != ACLCHECK_OK)
                elog(ERROR, "LOCK TABLE: permission denied");

 
 Yes. The my patch create a lock-permission level over this current code. 
It is global setting and example for all non-AccessShareLocks you must have 
pg_shadow->locktable privilege and 'write' privilage for table. 

 It is because I have users which needs update/insert access to tables, but 
I not want allow a lock command for these users. 

						Karel