
> > having a separate tuple for each individual kind of access 
> right will
> > consume an unreasonable amount of space --- both on disk and in the
> > syscache, if a cache is used for this table.
> 
> That's a valid concern, but unfortunately things aren't that easy. For
> each access right you also have to store what user granted 
> that privilege

each new grantor will create a new row. 
(thus the primary key needs to be extended: object, grantee, grantor) 
In the system cache you will probably want a key of object+grantee
with a merged result over the grantors.
Remember that you can be granted a certain priviledge by more than 
one grantor, thus your key was not correct to begin with.
(sorry I didn't realize that earlier)

> and whether it's grantable, and for SELECT also whether it 
> includes the
> "hierarchy option" (has to do with table inheritance somehow).

separate priviledge "h"

> 
> Say you store all privileges in an array, then you'd either 
> need to encode
> all 3 1/2 pieces of information into one single data type and make an
> array thereof (like `array of record privtype; privgrantor;
> privgrantable'), which doesn't really make things easier, or you have
> three arrays per tuple, which makes things worse. Also 
> querying arrays is
> painful.

I actually didn't mean real arrays, but e.g. a char(n) where each position 
marks a certain priv.  e.g. "SU-ID---" = with grant option, "su-id---"
without grant options.
This has the advantage of still beeing human readable and does not waste too

much space.

> So the break-even point for this new scheme is when 
> users have on
> average at least 1.4 privileges (78/54) granted to them on one object.
> Considering that such objects as types and functions will in 
> any case have
> at most one privilege (USAGE or EXECUTE, resp.), that there 
> are groups (or
> roles), that column level privileges will probably tend to have sparse
> tuples of this kind, and that object owners are short-circuited in any
> case, then it is not at all clear whether that figure will be reached.

Well I think it is not for us to decide, how the security system is used 
by the users. It has to be designed to allow heavy use, and still be
efficient.

Andreas

Tue, 6 Jun 2000 15:31:41 +0200 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: AW: AW: Proposal for enhancements of privilege syst
	em
Zeugswetter Andreas SB writes:

> Remember that you can be granted a certain priviledge by more than 
> one grantor, thus your key was not correct to begin with.

Oh, good catch. That will put things in perspective.

> I actually didn't mean real arrays, but e.g. a char(n) where each position 
> marks a certain priv.  e.g. "SU-ID---" = with grant option, "su-id---"
> without grant options.

Hmm, yes, that seems like a good idea. (Of course we'll run out of letters
before we have taken care of UPDATE, UNDER, USAGE. :)


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 8 Jun 2000 01:21:15 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: AW: AW: AW: Proposal for enhancements of privilege
 syst em