From: | Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE |
Date: | 2000-03-01 15:44:49 |
Message-ID: | Pine.LNX.3.96.1000301161406.6297D-100000@ara.zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-03-01 15:52:07 | BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) |
Previous Message | Tom Lane | 2000-03-01 15:36:14 | Re: [HACKERS] Re: Bugs in Postgres |