Mark's Code Fractal   

Globals and lookups have security entries in the Sys triplet of tables. All tables have a Sys entry, which acts to indicate Superuser status over that feature of a table across all clusters, tenants, and groups of data.

Cluster owned data has security entries in the Clus triplet of tables. Having a permission group name in Clus when the data is owned by a Tenant indicates that the members have access over all Tenant data for the Cluster, but not for other Clusters.

Tenant owned data has security entries in the Tent triplet of tables. Matching names in Clus indicate clusteradmin access to all the tenants in the cluster. Matching names in Sys indicate sysadmin access to all tenants in the system across all clusters in the system.

Joins will be allowed to go up to 7 GrpInc layers deep, or 8 group layers in total. More than that becomes too hard for most query optimizers to deal with. Only one of the three layers is probed at a time, starting with Ten[an]t if applicable, then Clus[ter], and finally Sys[tem].

There is a global "sysadmin" group and initial "admin" account as it's initial member, each Cluster has a "clusteradmin" group with "sysadmin" as an included group, and each Tenant has a "tenantadmin" group that includes "sysadmin". Because the "sysadmin" group only exists in the Sys triplet of tables, it gets found last in the search.

Note that join-by-SecName is very common in the model. SecName will have a 64-bit signed integer for an id, generated by JPA automatically and explicitly generated by RAM storage models. The main reason for this approach is to avoid the introduction of typos in the security specifications; you can't select a name that doesn't exist without explicitly adding it and knowing that you are doing so.

The 2.13 model already had "System", "Cluster", and "Tenant" SecScope values. The "SystemGroup", "ClusterGroup", and "TenantGroup" scopes have been added 2026-03-19, which will be implemented by applying the usual table level security checks, but also ensuring that the user doing the access is a member of the appropriate groupnameid in order to access individual records of the table. Only one table in a given hierarchy of tables can specify one of the *Group values, with the nameid column added to that table searched according to the SecScope value in code, rather than by referencing the security group tables directly. That way the usual superuser type behaviour can be implemented for the *Group security as well.

Loathe it though some may, administrators always can see a lot more than most users realize. If it isn't encryped, root sees it.