AW: AW: AW: Proposal for enhancements of privilege syst em

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