Re: ACL enhancements - Mailing list pgsql-hackers

From Karel Zak - Zakkr
Subject Re: ACL enhancements
Date
Msg-id Pine.LNX.3.96.1000306132215.14444A-100000@ara.zf.jcu.cz
Whole thread Raw
In response to ACL enhancements (was Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [HACKERS] Re: ACL enhancements  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
List pgsql-hackers

On Sat, 4 Mar 2000, Peter Eisentraut wrote:

> Karel Zak - Zakkr writes:

> I have given some more thought to the design of the pg_acl table (which
> should not be global if it wants to be SQL compliant). I realize that the
> size of my proposed 'one row per user/object/privilege' can grow rather
> huge (20 users, 100 tables/things -> probably ca. 5000 rows) but I see
> this as the best way some of the things (column access, grant options,
> roles) can be implemented in the first place and it will be much easier to
> verify the implementation because you can read it right out of SQL.

It must be fast! It is watchword for this project. The ACL is checked
for each query. I agree with one global pg_acl for one DB.

> I think caching can be done pretty effectively, too, since ACL items
> rarely change once they're set up. I'm inclined to ask other people's

Yes. IMHO will good initialize more user's information after connection start. 
Now is init only username, but we can save to any persistent struct full
user's pg_shadow row. (My bash (shell) not see the /etc/password before 
each command, it is initialize after bash start and it is persistent to 
its end.) The current code look at pg_shadow very often...etc.

> opinions on this item. Other than that, I think we have a winner
> here. Time to bring this up the the rest of the folks and draw up a
> project page ...

Agree. ...a project page with more details, implementation steps ..etc.
                        Karel



pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: AW: [HACKERS] DROP TABLE inside a transaction block
Next
From: Peter Eisentraut
Date:
Subject: Proposal for Grand Unified Configuration scheme