On Tue, 29 Feb 2000, Karel Zak - Zakkr wrote:
> On Tue, 29 Feb 2000, Thomas Lockhart wrote:
(I didn't get this email, but anyway ...)
> > The current acl storage scheme flattens the acl info into a single
> > string, with a special character ("=" as I recall) to delimit the
> > user/group name from the permissions. But by quoting the user name, it
> > is possible to create a user name which contains an equals sign,
> > screwing up the acl handling.
Try creating a user "group xxx" ...
> > If you are redoing the acls, a good first step is to fix this, perhaps
> > by recoding the acl field into a structure with at least two fields
> > for username and permissions.
This was precisely the idea. Everything else should fall in place more
easily after that.
> My acl idea:
> reloid | user_insert | group_insert | user_delete ..........etc
> ---------------------------------------------------------
> 12345 | {"karel", "peter"} | {"group1"} | {"karel"} ..........etc
This still has arrays. (shudder) Try getting the information 'Does Peter
have access to x?' out of that. I was thinking along the lines of
create table pg_privilege/pg_acl/? ( objoid oid, -- not only reloid, but types, functions, etc. userid int,
privilegechar, -- maybe 'U' update, 'I' insert, etc. grant_option bool
)
To be extended to cover column access as well. (Might have to be yet
another table.) Mathematically, this will be slower (especially since you
can't use SysCache on composite keys(???)) but similar schemas are
employed throughout by triggers etc.
> ...as I said: is the current acl/account schema good?
The SCHEME is good. The SCHEMA isn't.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
