Provides the gBase classes for modelling a MySQL 5 server as an extension, in the AcsAddon MySQL, of the generic ARoad0.gBase package. The aim is to simulate the MySQL components and properties. The MySQL ACS Addon has 9,000 physical source lines of code (generated using David A. Wheeler's 'SLOCCount').
OVERVIEW
To simulate the MySQL server, the features are provided first by a configuration of the Access Road core functions, in the generic gBase package. This is the responsibility of the class ACSFactoryMySQLImpl, after its configuration by the class MySQL.gWork.AcsFactoryMySQL that provides:
modelling of the MySQL server, through the using of UserID, GroupID, GroupID tree, Resource, Directory, VirtualFolder, VirtualFolder tree, AclEntry, conditional AclEntry, inherited AclEntry and hard aliasing,
31 MySQL ACS rights, and no direct use of the metarights,
13 main types of Resources, 13 main types of EligibleParties including 3 types for the standard GroupTree, 3 main types of VirtualFolders,
36 ACS type policies for the GUI and the classes GroupID, Directory, Resource and VirtualFolder,
25 specialized rights for AclEntry,
3 automatic associations for a new MySQL database,
no automatic roots in the ACS MySQL parent.
The simulation of the MySQL server is then completed by the way of the MySQL AcsAddon, delivering the following features:
the inherited AclEntries, in MySQL.gBase,
the complex AclEntry sorting to simulate the MySQL account priority rules, in MySQL.gBase and MySQL.gWork,
enforcing one first host per account, in MySQL.gBase,
VirtualFolder to simulate the MySQL view, enforcing to have elements only from the database, in MySQL.gBase,
VirtualFolder hard alias, in MySQL.gBase, as Actor that may run under a VirtualFolder UserID. This UserID is added to the VirtualFolder constructor arguments. The alias is the unique mean to have an access to the view.
conditional overlaying of the received AG context on the VirtualFolder alias, where the condition is a non-null current UserID, in MySQL.gWork,
handling of the '%' and '_' characters to produce the pattern-name groups, and managing the constraints on the membership relations between them, in MySQL.gBase,
BasesSetMySQL to model a set of databases, in MySQL.gBase,
ProxyMySQL to model a proxy account, including the use of the generic property 'SoftAlias' but without managing of the soft aliasing by the ACS, in MySQL.gBase,
specific constraints on the database AclEntry, with simple host groups having rights only on the databases, and the setting of some specific mixed AclEntries from two non-conditional AclEntries, in MySQL.gBase,
access path deleting if there is another path having priority, in MySQL.gWork.
2 properties 'inherited rights list' and 'primary rights map' to help the user to understand the applicable rights, in MySQL.gBase,
about 25 error messages at the creation of a MySQL object, in MySQL.gBase.
subACS for 3 standard groups, in MySQL.gBase.
These features are presented in the following sections of this page.
There are 11 new classes in the MySQL.gBase package: DirectoryMySQLImpl, ResourceMySQLImpl, GroupIDMySQLImpl, UserIDMySQLImpl, VirtualFolderMySQLImpl, ActorMySQLImpl, BasesSetMySQLImpl, ProxyMySQLImpl, ACSMySQLImpl and, for the utilities, BaseUtilityMySQLImpl and ACSFactoryMySQLImpl. In the MySQL.gWork package, there are NodeRightsMySQLImpl, LinkRightsMySQLImpl for the access paths search, and the mandatory class AcsFactoryMySQL to create the ACS. To implement the MySQL rights selection algorithm, the inherited AclEntries feature allows to put in each Resource, the AclEntries of its direct and indirect parents. The core Access Road functions do not include the management of the inherited AclEntries. This is the first reason to define a MySQL AcsAddon.
All the classes in this package are subclassed from the generic gBase package, and they implement the MySQL.gBaseInterface interfaces. Most of these classes may be viewed as having a multiple inheritance: the first one from a generic gBase class, and the others from a set of MySQL interfaces. For instance, while DirectoryImpl extends ResourceImpl, DirectoryMySQLImpl does not extend ResourceMySQLImpl but ARoad0.gBase.DirectoryImpl. DirectoryMySQLImpl copies the code of the ResourceMySQLImpl methods that implements the interface ResourceMySQL.
FEATURES OF MYSQL
The requirements for the MySQL access controls are described in http://dev.mysql.com/doc/refman/5.5/en/request-access.html and the near pages. The following overview is about the features the AcsAddon MySQL provides, and it explains why the generic functions of the core cannot provide them.
MySQL uses a specific algorithm to select the privilege rights of a given resource, and Access Road uses a proper model to simulate these rights and this algorithm with AclEntry. The algorithm modelling is based on the sorting of the AclEntries, and produces a set of elementary MySQL rights. The set of the applicable MySQL rights through privileges are selected by an algorithm which may be summarized, for a given 'user@host' right user, by:
it is mandatory to have one server (or global) privilege (no access otherwise)
AND one database privilege OR (one user privilege on database AND one host privilege on database)
AND one table/routine/view privilege
AND one column privilege
A routine is there a stored function, a stored procedure or a trigger. The term server/database/table/view/routine/column privilege defines there a set of rights a privilege statement defines for a given 'user@host' right user. Privileges on an object are applicable only if it is the access target, or if it is a parent of this target. For instance, if the target is a table, the applicable privileges are from the server, its database and the table itself. Table, routine and view privileges are at the same level under a database, and a column is a child of a table. At each of the 4 lines of this algorithm, a privilege sorting puts the most-specific values first and least-specific values at the end of the list. This sorting is explained later. For instance, we will see that an account is more specific than a pattern-name group where the group contains the same account. When the server looks for matching entries, it uses the first match that it finds for EACH PARENT LEVEL. This is the end of the MySQL requirements on rights selection, using the MySQL own vocabulary.
A 'privilege' in the MySQL vocabulary is simulated as an AclEntry in Access Road. PrivilegeForLinks has not been choosen to simulate the MySQL privilege. The main justification is that AclEntry allows simple conditional rights for a given couple (source, target), controlling if the source is member of the condition group. This feature is necessary to handle the 'user@simple host' rights, where 'simple host' is a GroupID. A MySQL user is an UserID being member of a first host. It is called simple host because it simulates a true computer, while a pattern-name group is a mean to designate a set of simple hosts through a name like '120.38.%' or 'down_'. The second justification of using AclEntry is that the internal AclEntries propagate the AG context of an acces path, so the local AG context of the ACL target is not applied, while the Privileges does not propagate the AG context.
HOW THE MySQL STRUCTURE IS MANAGED
'MySQL server' is the root of the structure of Resources. Its children are databases or bases sets. Only databases have children. They are tables, view delegates, stored procedures, stored functions and triggers. Only tables have children, and they are columns and indexes. A view delegate has a generic hard alias, and it is a view. A ProxyMySQL is the alias of an UserIDMySQL, but without using the generic hard alias or the soft alias features. The Proxy handles simply one CAlias property whaich has been designed for the generic soft alias. The databases and the bases sets are called 'database-related targets', because all the AclEntries of the bases set are copied into the direct ACL list of every database that matches the bases set name. For instance, the bases set named 'on%' matches the database named 'one', and all the 'on%' direct ACL are then copied into the direct ACL list of the database 'one'. These terms define the main types of the MySQL ACS access targets.
An user in MySQL is simulated by an UserID having the type 'account'. A simple host in MySQL is simulated by a 'host' GroupID. In MySQL, it is possible to set with one statement like 'tom@%' some rights for all the accounts 'tom' whatever their current hosts. From the security point of view, this feature is not acceptable, because there is no way to state it is always the same 'tom'. This is why Access Road allows to create accounts like 'tom', 'tom(2)' and tom(A) from 3 differents hosts, for setting their common rights through a group named 'tom§@%', in this example of MySQL statement.
The group 'localhost' models the MySQL server host. Otherwise, a new host has to model an open ACS. The name last component of a new host must have the form 'xxx:yy:zzz:tttt', and it models then the ACS ' xxx:: yy:: zzz:: tttt:: '. There is exactly one simple host per account, at the creation of the account, and this first host cannot be changed.
A pattern-name group is created by the user to contains all the accounts or groups having a given pattern in their names. Its name contains one of the two '%' and '_' wildcard characters:
- '%' matches any number of characters, even zero characters,
- '_' matches exactly one character.
While MySQL Server allows to have two wildcards, or more, in the same name of a pattern-name group, Access Road does NOT permit it, because the algorithm sorting for these names is not specified and quite confusing. An IP wildcard value can match only IP addresses, and not host names. '1.2.example.com' never matches '1.2.%'. The MySQL ACS addon ensures that accounts or groups are members of the pattern-name groups that match to them. Hosts groups and accounts-for-hosts groups are the two types of pattern-name groups. They are defined hereinafter:
A pattern-name hosts group may be created by the Access Road user to contain all the hosts having a given pattern in their names. '1.2.%' is an example of hosts group nick name. A hosts group may have ACL only for the database level.");
A pattern-name accounts-for-hosts group may be created by the Access Road user to contain all the accounts having a given pattern, like 'tom§@1.2.%' for 'tom' and 'tom(2)'."); The pattern-name accounts-for-hosts group nick name has the form 'nnnn§@YYYY', where 'YYYY' contain a wildcard character, and 'nnnn' is the nick name of an account, like 'tom'. In the example, 'tom' and 'tom(2)' are set by Access Road as members of the group 'tom§@1.2.%'. This is proper to Access Road, since MySQL would use 'tom@%' in the privilege statement.
A proxy is an UserID that uses an proxied account to access. A proxy has no own rights. Any account may have several proxies.
A simple host group in MySQL has only accounts and proxies as members. Accounts and simple host memberships are created by the user. A hostS group has only simple hosts as members. An accounts-for-hosts group has only accounts, not proxies, as members. From their names, Access Road sets the members of these two groups.
ACS TYPE POLICY
This section presents the ACS type policies on ACL and GroupIDs. A GroupID may be an ACL source or an ACL condition group, but this is not true in all cases. Some complex requirements define the type-oriented constraints on groups. The condition group in a simple-condition ACL is always a simple host. For instance, a pattern-name accounts-for-hotst group cannot be a conditional group in an ACL. This is specified in the ACS type policy by the key 'GroupID.ConditionalAclGroup' the class gWork.AcsFactoryMySQL sets at the creation of the MySQL ACS. On the other hand, the pattern-name accounts-for-hosts groups may be used as ACL sources in non-conditional ACL. This is specified in the ACS by the key 'Source.AclRightsSet.Type.pattern-name_accounts-for-hosts group' for the specialized AclEntry rights.
The list of the 25 specialized AclEntry rights is not included in this page. Based on the ACS generic properties, the full list of used policy keys is the following: 'CreationByBeamer.NoType', 'GroupID.NoPrimaryGroup', 'GroupID.NoUserIDAsMember', 'GroupID.TypesOfMemberFor.host', 'GroupID.TypesOfMemberFor.host byAcsCreator', 'GroupID.TypesOfMemberFor.pattern-name_accounts-for-hosts group', 'GroupID.TypesOfMemberFor.pattern-name_hosts group', 'GroupID.TypesOfMemberFor.byAcsCreator standard', 'GroupID.TypesOfMemberFor.byAcsCreator standard pattern-name_accounts-for-hosts group', 'GroupID.TypesOfMemberFor.byAcsCreator standard pattern-name_hosts group', 'GroupID.TypesOfMemberFor.byAcsCreator standard for simple hosts', 'GroupID.ConditionalAclGroup', 'Directory.TypesOfChildFor.NULL', 'Directory.TypesOfChildFor.byAcsCreator', 'Directory.TypesOfChildFor.MySQL server byAcsCreator', 'Directory.TypesOfChildFor.virtual_objects byAcsCreator', 'Directory.TypesOfChildFor.pattern-name_bases set', 'Directory.TypesOfChildFor.database', 'Directory.TypesOfChildFor.table', 'VirtualFolder.TypesOfChildFor.NULL', 'VirtualFolder.TypesOfChildFor.no-child node', 'VirtualFolder.TypesOfChildFor.root for a set', 'VirtualFolder.TypesOfMemberFor.view', 'VirtualFolder.TypesOfChildFor.view', 'Resource.NoAccount', 'Resource.NoConditionalACL', 'Resource.NoNonConditionalACL', 'Resource.OneConditionGroupInACL', 'Actor.NoNullCurrentAccount', 'Resource.TypesOfSourceForConditionalACL.MySQL server byAcsCreator', 'Resource.TypesOfSourceForConditionalACL.database', 'Resource.TypesOfSourceForConditionalACL.table', 'Resource.TypesOfSourceForConditionalACL."stored_function', 'Resource.TypesOfSourceForConditionalACL.stored_procedure', 'Resource.TypesOfSourceForConditionalACL.pattern-name_bases set', 'Resource.TypesOfSourceForConditionalACL.table_column'.
TYPES OF ACL
In the ACS MySQL, the effective rights of a pair (user, host) on a resource are selected by a two-steps algorithm, derived from the MySQL specification, that is described hereinafter:
At the first step of access control, only the ACL on the root 'MySQL server' are implied to select the first pair (user, host or accounts-for-hosts group) that user matches. An accounts-for-hosts group contains some accounts to which it transfers the rights of all its ACL. Its behavior is like a Privilege having the type LINKED_IF_ALL_SOURCES. This pair (user, host or accounts-for-hosts group) is called by MySQL the current user, and it may be the initial pair (user, host) or not. For instance, all the effective rights of a pair (jerry, localhost) may be provided by the current user ('jerry', '%'). The AclEntries on the root 'MySQL server', for this first step of access control, may be:
- conditional user/host ACL on the root 'MySQL server', EXCLUSIVE OR,
- non-conditional 'accounts-for-hosts group' ACL on the root 'MySQL server'.
Into this list, all the conditional ACL are before all the non-conditional ACL. But the ACL list is not totally ordered, since the accounts conditional ACL are not sorted if the accounts are not 'anomymous'. If a right is granted at this first step (at least the 'USAGE' right), some complementary rights may be added, for the SAME current user, at each parent level from the database to the resource direct parent, as inherited ACL, then other complementary rights may be added from the direct ACLs of the resource. At each of these parent levels, and for the resource itself, into the sorted list of inherited or direct ACLs, the FIRST ACL or the FIRST couple of ACL for the current user, if any, defines the effective rights, at this level, for the pair (user, host) on the resource. This is the sens of the 'EXCLUSIVE OR' into each line of the two-steps algorithm. This first-selected-single-output rule is also applied into each category of ACL, like into the sorted list of the non-conditional 'accounts-for-hosts group' ACL for a resource.
The database and the bases set are both called 'database-specific target', because the bases set AclEntries are copied into the direct ACL list of every database that matches the bases set name. This copy is mainly provided by the class BasesSetMySQLImpl. For instance, the bases set named 'on%' matches the database named 'one', and all the 'on%' direct ACL are then copied by BasesSetMySQLImpl into the direct ACL list of the database 'one'. As we have seen, if a right is granted at the first step on the root 'MySQL server', some complementary rights may be added from the other levels:
first, one result from the database-specific targets, where the three different types of statement are sorted in this order:
- AND ((conditional user/host ACL on a database-specific target
EXCLUSIVE OR
non-conditional 'accounts-for-hosts group' ACL on a database-specific target)
EXCLUSIVE OR
(user non-conditional ACL on a database-specific target AND host non-conditional ACL on the database-specific target)),
and secondly, some complementary rights may be also added, for the SAME current user (user, host or group of hosts), from the rights on all the database children which are parents of the resource or which is the resource itself:
- AND (conditional user/host ACL on a table EXCLUSIVE OR non-conditional 'accounts-for-hosts group' ACL on this table),
- AND (conditional user/host ACL on a column EXCLUSIVE OR non-conditional 'accounts-for-hosts group' ACL on this column),
- AND (conditional user/host ACL on a routine EXCLUSIVE OR non-conditional 'accounts-for-hosts group' ACL on this routine),
- AND (conditional user/host ACL on a view delegate EXCLUSIVE OR non-conditional 'accounts-for-hosts group' ACL on this view delegate),
Routines are the stored functions and the stored procedures. The rights on a resource may use any direct ACL rights on itself and also may use any of the rights on any direct or indirect parent. The rights on a database are the most complex. They use the ACL on the root, on the related bases sets and on this database.
The first applicable ACL is selected at each parent level, except for the to-be-mixed ACL on the databases: (user non-conditional ACL on a database-specific target AND host non-conditional ACL on the database-specific target). This is applicable only if the previous ACL at this level do not match, because the ACL sorting puts first the conditional user/host ACL, then the non-conditional 'accounts-for-hosts group' ACL, and so, the to-be-mixed ACL are always at the end of the sorted list for a database. This selection rule explains why the ACL sorting into each ACL list is so important.
ACL HANDLING AND INHERITANCE
Among the conditional user/host ACL, only one ACL matches a given pair (user, host). There is no sorting to apply among the simple hosts into this category of ACL. On the other hand, for several category of ACL into this description, like for instance 'non-conditional 'accounts-for-hosts group' ACL on the root 'MySQL server'', two specific ACL sortings are required, so that the first matched ACL is get for the effective rights. For the 'non-conditional 'accounts-for-hosts group' ACL and the host to-be-mixed ACL, the first sorting is based on the hosts group names, where for instance '192.168.1.%' is selected before '192.168.%' because it is sorted first.
For the database, a mixed ACL is not a true AclEntry the beamer may display. It is the result of the combination of a non-conditional ACL (UserID, database) and a non-conditional ACL (GroupID, database), and only for the rights the two ACLs have in common. It simulates when there is no host name in the Host column of the MySQL DB table, for a given account. A mixed ACL appears only as a specific key in the map of the primary inherited rights, in the beamer. The primary rights are the rights of each matched pair (user, host or hosts group of accounts-for-hosts group). This is the most complex case to handle.
For the bases set ACL at the database level, there is an another sorting for the bases set names, where for instance 'on%' is selected before '%'.
To implement the 'AND' clause on the MySQL privileges at each parent level, for a given 'user@host', the AclEntries of the parent, like the root 'MySQL server', are inherited by each child Resource in the tree. This is also true for any Directory (a database, a table) for which the AclEntries are copied to their direct and indirect children, as inherited ones. By this way, the gWork classes having to define the effective rights may read quickly the applicable properties of each Resource.
The AclEntry rights in the MySQL ACS are applied only from a GroupIDMember to a Resource. An Actor (for instance a MySQL trigger or a MySQL view hard alias) has no proper AclEntry as source, and it gets its source rights, if any, through its current UserID/GroupID or its alias reference. A VirtualFolder (a MySQL view) is an access target only as the hard alias reference of the Actor having the role of view delegate.
A host in MySQL is seen in Access Road as a GroupID having a simple 'host' type, with the special case of the group 'localhost' that has the type 'host byAcsCreator' to forbid its deleting by the Access Road user. In all cases, there is a constraint to enforce one first immutable simple host per account. To simulate the connection of an user from 3 hosts, it is necessary to define 3 different accounts in 3 host groups as members of a pattern-name account groups. To separate the accounts, the names use the convention '(X)' to terminate the user name, like 'user@host_one', 'user(A)@host_two' and 'user(7)@host_three'. This is the responsibility of the GroupIDMySQLImpl class. Since there are also pattern-name host groups, where the members are the simple hosts, the GroupIDMySQLImpl class manages also these members.
A pattern-name group may be created by the user to contains all the accounts or groups having a given pattern in their names. The convention is to use in the group names, the two '%' and '_' wildcard characters. So, the account 'aicha' is put in the pattern-name group '%cha'. The AcsAddon, in the classes UserIDMySQLImpl and GroupIDMySQLImpl, ensures that the accounts or groups become members of the pattern-name groups that match to them. The host pattern-name groups are groups of groups, since they have also some simple hosts as members.
The host groups may be non-conditional ACL sources only for the directories that are databases, just like accounts. The accounts-for-hosts groups may be non-conditional ACL sources for any resourceMySQL. All the other AclEntries are conditional ACL for a UserID as source. A MySQL account with a blank user name is an anonymous user. Since an UserID name cannot be empty, the simulation uses the UserID name 'anonymous' to simulate a MySQL anonymous user. These features are the responsability of the classes which implements ResourceMySQL.
For most of the Resources which are children of the AclEntry target, the AclEntry becames an inherited ACL. The indexes have no inherited ACL. The inherited AclEntry is listed without changing in the child, so it keeps its source, its target and condition group, if any. The editing of an AclEntry is quite slow, since the changing has to be propagated to all the children of the target. But thus, the access paths search algorithm is faster. The rights search has to catch the first matched AclEntry (or two non-conditional ACL, only for the database) into the inherited ACL list, for each parent level, and to add it to the direct ACL list of the target, for a given couple 'user@host'.
For instance, a MySQL column inherits the direct AclEntries of its parent table, and also those from its database, as an indirect parent. The core access path algorithms, as usual, search if a given account/group or group has some AclEntries to the column, and what are the rights. To do the work, these algorithms call some specific methods on the classes NodeRightsMySQLImpl and LinkRightsMySQLImpl, following the AcsAddon pattern. These methods are responsible to implement the selection of the matching direct and inherited AclEntries of the target. They use the lists and maps the target delivers, implementing the ImmutableResource interface with the methods getEorImmutableL_TargetInheritedAclEntries and getM_TargetInheritedACLRights, and implementing the ResourceMySQL interface with getM_TargetInheritedACLRights. The main algorithms to get rights are coded in the NodeRightsMySQLImpl class, with the large methods withAclAccessThroughNodesTree, getL_accessRightsThroughNodesTree and detectL_aclEntryRights.
ACL SORTING AND DISPLAYING
Sorting the AclEntries is the important responsibility of the class BaseUtilityMySQLImpl, called by the ResourceMySQL implementations. Generally speaking, the sorting for ACLs having a different parent level is independant. For the same parent level, the ACL are sorted first from the more-specific sources to the least-specific ones, then they are sorted with a similar logic for the hosts (the ACL condition group) and finally, with a special sorting for the bases sets, if any. This sorting is both for direct AclEntries and inherited AclEntries. The method BaseUtilityMySQLImpl.addInSortedAclList) inserts a new AclEntry into the ACL list, at the right MySQL sorting, and for a given access target. The method handles three independant cases:
if the _acl target is not a database-specific target (database or base set),
if the _acl target is a database-specific target and _acl is NOT a to-be-mixed ACL,
if the _acl target is a database-specific target and _acl is a to-be-mixed ACL.
The method BaseUtilityMySQLImpl.addInSortedAclList) acts so a commutator for the BaseUtilityMySQLImpl methods addAclNOTForDatabase(), addAclForDatabaseNOTForToBeMixedAcl() and addAclForDatabaseForToBeMixedAcl().
Handling the sorting order logics to the AclEntries is the responsability of the classes ResourceMySQLImpl, BaseUtilityMySQLImpl and DirectoryMySQLImpl.
To facilitate the using of Access Road, the GUI has to recall the meaning of most of the AclEntries in the MySQL ACS. The beamer try to explain, as far as possible, how the AclEntries simulate the MySQL 'user@host' rights on a MySQL object. This is the role of the sorted list of inherited AclEntries of a ResourceMySQL, and the map of the primary rights. The keys of these primary are described later into this page.
HOW THE MATCHED RIGHTS ARE SELECTED
The MySQL server analyzes the rights in a process where it takes the first applicable row in the rights tables. In most cases, such a row is simulated through an ACL in Access Road. A matched ACL is one of the selected ones for a given current user and a given target. Except for the hosts group ACL, a matched ACL has always non-null rights. Each target has a sorted list of direct ACLs, in its 'ACL' tab, and a sorted list of inherited ACLs, in its 'ACL Inheritance' tab. In most of the cases, an inherited ACL is an ACL for which its target is a direct or indirect parent of the access target, except for the bases set ACL copied into the matched databases ACL lists.
We have seen that at every parent level, through a parsing of the sorted list of ACL, the first ACL that matches the current user, if any, is the only applicable ACL. The single exception is for the selection of two to-be-mixed ACL at the database level (see above).
(R1) The first ACL SORTING RULE is to apply the order used in this presentation to describe the varied types of AclEntries, into the previous section HOW THE RIGHTS ARE MANAGED. Then, a matched conditional user/host ACL is always selected before any matched non-conditional 'accounts-for-hosts group' ACL. For the database level, a matched non-conditional 'accounts-for-hosts group' ACL is always selected before any matched to-be-mixed ACL couple.
For the root 'MySQL server' and any database children, there are two other sorting rules for their AclEntries:
(R2) the conditional ACL of the 'anonymous' account at the end of all the conditional ACL for the other accounts.
(R3) among the non-conditional ACL, which are all for accounts-for-hosts groups, the hosts group sorting is applied (there is no ordering among the accounts). The ACL list is not totally ordered, since the accounts conditional ACL are not sorted if the accounts are not 'anomymous'.
For the databases, the ACL sorting is more complex, since the (R1) and (R3) rules remains but they are completed by:
(R4) replaces (R2): the ACL of the 'anonymous' account at the end of all the ACL having the same type for the other accounts.
(R5) the ACL for the 'database' target are put before the ACL for a 'bases set' target.
(R6) among the ACL for a 'bases set' target, and having the same type, the bases set sorting is applied.
(R7) among the to-be-mixed ACL, the ACL of host(s) is put after the ACL of account.
(R8) among the to-be-mixed ACL of account, the set R4/R5/R6 is applied.
(R9) among the to-be-mixed ACL of host(s), the hosts group sorting is applied first, then the set R4/R5/R6.
A last sorting rule is applied to the inherited ACL list, to put first the ACL for the root, then the ACL for the database level, and so on. This sorting has no impact on the selection of AclEntries, because the selection at each parent level is independent.
The bases set sorting is complex and beyond the specification. The simpliest rule is to put first the databases, before the bases sets, and there is no sorting among the databases. A typical example of sorted list for database and bases sets, having a match to the database 'one' for each item, is the following list: 'one', on%', 'on_', 'o%', 'o%e', 'o_e', '%', '_ne', '%e', '%ne'.
The hosts group sorting is different and also beyond the specification. The simpliest rule is to put first the simple hosts, before the hosts groups, and there is no sorting among the simple hosts. A typical example of sorted list for host(s) group, having a match to the simple host 'localhost' for each item, is the following list: 'localhost', localhos_', '_ocalhost', 'localhost%', 'localhos%',
The simulation of these sortings is a great feature for the Access Road user!
AG CONTEXT PROPAGATION
As a generic Access Road rule, the internal AclEntries propagate the direct Account/Group context. The received context overlays the AG context of the target, if it is not null. The overlayed AG context is there the current context of an Actor, as an intermediate node in an access path. In the MySQL ACS, the Actors are stored procedures and stored functions, and they may have a current UserID but no current GroupID. The Actors may also be table triggers or view alias. In all theses 4 cases, letting the Actor be a proxy needs an AclEntry with an executing right on this Actor. A MySQL view is simulated as a VirtualFolder, and it has an Actor as alias, called the view delegate. To simulate the access to the view, an access source must have rights on the view delegate.
The proper Actor AG context is required in the MySQL ACS, for any type of Actor as intermediate node in an access path, each time there is a non-null current UserID and there is an executing right on the Actor. This allows to use a trigger or a stored procedure as a proxy in an access path. This is typically also true for the VirtualFolder alias, in the MySQL DEFINER mode of a view. The view mode depends on the existence of a current account (the DEFINER) for the VirtualFolder alias as Actor. This feature is the responsability of the class LinkRightsMySQLImpl, in the MySQL gWork package, through the method updateAGrunningContext. On the other hand, once there is an access to the MySQL view, the rights on the view members do not depend on the previous rights on the view. This is why the MySQL ACS does not use the VirtualFolder ACS property for managing a mandatory rights propagation to the members. The generic gWork classes provide the detection for the VirtualFolder links, through a call to LinkRightsMySQLImpl.
VIEW DEFINER MODE
The DEFINER mode is the default one for the MySQL views. For having a view, the simulation must create a VirtualFolder with an UserID as parameter of the constructor. The UserID becomes the account of the AG context of the view delegate to create. This feature implies the creation of a VirtualFolderMySQLImpl class in the AcsAddon gBase package, as subclass of VirtualFolderImpl in the generic gBase package. The view definition is “frozen” at its creation in MySQL, but it is not useful to extend this constraint to the view simulation in Access Road. As Actor, the view delegate in the Resources tree runs under the UserID and GroupID passed on to the VirtualFolder constructor of the view. This is also the responsibility of the VirtualFolderMySQLImpl constructor.
PRIMARY RIGHTS KEYS
This section is about the keys into the primary rights map. Each parent level may produce a matched key for a given couple user/host and a target. Into the primary ACL rights map, the map key may have varied forms, where the parent order is always at the end. The parent order tells the distance from the target to the parent which delivers the referenced rights. For instance, the direct parent of a resource has the string '1'. The direct parent of this parent has the string '2' as parent order, and so on. Into the two rights maps, the single difference between the keys is that the key for the primary rights is a String form of a Name, and the global rights key is the same Name.
The ten key forms are listed hereinafter:
- (user name @ host name last component) :: parent order, for instance 'one :: mysql :: jerry@localhost :: 2',
- Proc:: (user name @ accounts-for-hosts group name last component) :: parent order, for instance 'Proc:: one :: mysql :: jerry(2)@192.168.1.% :: 0',
'Proc' is there a generic tag that means 'processed rights', to tell the key and its rights are not get from the direct reading of a real ACL. These two first forms are the only used ones when the parent level is not a database. They are also used for a database, but the followings are additional forms in this case:
- Proc from 'bases set name last component':: (user name @ host name last component):: parent order,
- Proc from 'bases set name last component':: (user name @ accounts-for-hosts group name last component) :: parent order,
- ProcMixed:: (user name @ host name last component) :: parent order,
- Proc Mixed from 'bases set name last component':: (user name @ host name last component) :: parent order,
- Proc Mixed from 'bases set name last component' from 'bases set name last component'>:: (user name @ host name last component) :: parent order,
- Proc Mixed:: (user name @ hosts group name last component) :: parent order,
- Proc Mixed from 'bases set name last component':: (user name @ hosts group name last component) :: parent order,
- Proc Mixed from 'bases set name last component' from 'bases set name last component'>:: (user name @ hosts group name last component) :: parent order.
In this catalog of key forms for the database, 'Mixed' means this is a virtual mixed ACL, and 'from 'bases set name last component'' means a bases set ACL is the real ACL from which the virtual ACL is derived. The tag 'Mixed' is proper to MySQL but it may be reused in another ACS Addons. The tag 'from 'xxxx'' is a generic form another ACS Addon may use. A key contains two times 'from 'bases set name last component'' when there are both a real bases set ACL for the user, and a real bases set ACL for the host or the hosts group. These key forms are designed to help the Access Road user to find the origin of a key into a rights map. A key has exactly one origin, which is one real ACL in most of the cases, except the virtual mixed ACL where two real to-be-mixed ACL are processed. The rights map keys of a parent level are not sorted following the ACL sorting, or following any other sorting. The value in a rights map is always a non-null StringRight array. This array may be empty only for a mixed virtual ACL.
LIMITATIONS OF THE MYSQL SERVER SIMULATION BY ACCESS ROAD
Like any AcsAddon, this package offers gBase classes which may be used by any generic ACS or by an ACS from another AcsAddon. Nonetheless, the classes in this package are designed to work together. A single class may be reused, but after a careful study of its code.
The MySQL server simulation has some limitations, as described following:
the security-related mysqld options are not managed.
the REFERENCES right is unused in MySQL; it is not modelled.
the administrative rights, that is the rights to change the current rights, are GRANT OPTION and CREATE USER. They do exist in the simulation, but the rights transfering to other users is not modelled. They are not used to provide simulations on the new access paths when an user has made some administrative operations to grant its proper rights to another user.
Access Road does not accept hosts and pattern-name names including more than one wildcard, both for the host names and the database names.
the character sequences '\%' and '\_' are not managed in the pattern-name names. For MySQL, a blank Host value in the host table means "any host". A blank Db value in either table means "any database". A blank user value means "any user". Access Road does not implement this feature, because all blank names are forbidden.
rights cannot be granted separately for a stored function and a stored procedure with the same name.
for a host value specified as an IP address, there is no handling of the netmask.
a MySQL privilege may be granted globally for all objects of a given type in all databases, and Access Road does not provide this feature.
the strict SQL mode is not managed.
MySQL enables to grant privileges on databases or tables that do not exist, while Access Road cannot create an ACL if the database or the table is not there.
for the routines and the views, Access Road forbids to have a Host that is not the host group of the Definer account. This is not the behavior of the MySQL Server, where it is possible to have a disabled Definer.
by default, MySQL automatically grants the ALTER ROUTINE and EXECUTE privileges to the routine creator. This behavior can be changed by disabling the automatic_sp_privileges system variable. Since the concept of routine creator does not exist for it, Access Road never grants automatically these two privileges for a routine.
Ease-of-use: medium.
Reliability: medium. There are no known bugs.
Version: MySQL ACS Addon 0.7.1