Skip site navigation (1) Skip section navigation (2)

Re: ACL enhancements

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: ACL enhancements
Date: 2000-03-06 13:47:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.


In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-03-06 15:59:57
Subject: Proposal for Grand Unified Configuration scheme
Previous:From: Zeugswetter Andreas SBDate: 2000-03-06 10:27:43
Subject: AW: AW: [HACKERS] DROP TABLE inside a transaction block

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group