![]() ![]()
Access
Road 0.7
|
|
About
the s
|
![]()
|
About
this guide
The Access Road documentation includes a second tutorial named 'two-hours tutorial for designing access controls'. It is recommended to read first this document, because it introduces the simulation of MySQL Server®. It shows how to create an ACS for simulating this software. It demonstrates the capacities of Access Road through the example of the MySQL Server AclEntry. More generally, it is recommended, to save time, to read first the 3 basic tutorials for Access Road. This guide discusses the following issues about the simulation of MySQL Server:
For the software developer, the reference documentation is the extended Javadoc documentation for Access Road. It includes a full description of this ACS add-on. This present documentation is published under a FDL license. |
|
How
the MySQL Server ACS handles the AclEntries
The management of access controls by the MySQL server ACS may be summarized by 6 cases. The simulation of the MySQL server access control can take the following forms:
The second tutorial for Access Road presents the 3 first forms of access control. The virtual mixed AclEntry is described in a following section. The USAGE right in MySQL has some ambiguity. Its meaning varies following the context. At the global level on the root 'MySQL server', it means 'no rights at this level but rights are possible at another levels', while at the other levels, it means 'no rights at this parent level'. Access Road comments this right to recall this specificity.
|
![]()
|
Introducing
the MySQL host and its accounts
Under the standard groups tree in the explorer, the group '|simple hosts|' contains all the hosts the MySQL server knows. Those hosts have simply the type 'host'. At the creation of a MySQL Server ACS, '|localhost|' is the single known host. By convention, the local host is the operating system on which the MySQL Server runs. Any new MySQL Server host has to be the image of an ACS in the information system. For instance, let's say there is a Linux Ubuntu ACS named 'IO:: two:: bun2:: '. It is possible to declare such a host in a MySQL Server ACS, as a new GroupID having the type 'host'. The GroupID name 'IO:two:bun2' has to be used to allow the ACS add-on to match it to the good ACS in the information system. The new GroupID is added as member of the standard group '|simple hosts|'. In a MySQL Server ACS, a host has then a name that fulfills with a precise form, because the name is an image of the ACS name. Following the same logic, a MySQL UserID may be added as member of the host 'IO:two:bun2' only if it is the image of an UserID in the associated ACS. For instance, to create the MySQL Server ACS UserID 'games' with 'IO:two:bun2' as first host, it is mandatory to have an UserID 'games' in the ACS 'bun2'. In this case, the association manages the collisions of names among the UserIDs. For instance, there is only one account 'jerry' under a given ACS, but 'jerry' may be an UserID into several ACS. This is why the MySQL Server ACS addon allows to create an account 'jerry(2)' with 'IO:two:bun2' as first host. The general form 'jerry(any_character)' defines a so-called pattern-name account. It may seem strange to declare two accounts for the same person 'jerry' into two host servers. From an administration point of view, it is time-consuming and MySQL has not taken this way. The MySQL account is associated to a host or a group of hosts, using MySQL right statements like: GRANT ALL ON db1.* TO 'jerry'@'localhost'. On the other hand, Access Road simulates the MySQL Server and all the objects it handles, but not the organization. Access Road is a support for security analysis. It has to model that, say, the account 'jerry' under the host '192.168.1.2' is NOT the account 'jerry' into '192.168.1.1', since MySQL Server may attribute distinct rights to them. Even if the MySQL Server is configured to use the same password for the two 'jerry', offering or not the same rights from different hosts is an organizational issue. It remains true that the two accounts are not technically the same 'jerry'. Considering other design constraints like the mixed ACL, it is not efficient to model a MySQL pair (user, host) as one single Access Road UserID. From the software point of view, these 'jerry' are indeed different accounts having separate first hosts, and sometimes separate rights. Access Road does not simulate the privilege tables (user db tables_priv columns_priv procs_priv). The overall simulation of the MySQL Cluster distributed privileges is exactly like the simulation of a single MySQL Server. The simpliest and efficient simulation of a MySQL Cluster is then to model it as one MySQL Server. The second way is of course to model each SQL node with its local components and privileges tables. Views and stored procedures are not copied on all the MySQL nodes of a cluster by the installation script 'ndb_dist_priv.sql', but they may be copied manually. This is easy to simulate in Access Road, like the copying by the basic programs. If the privilege tables are modeled by Access Road on each MySQL node, then modeling the NDB API and ClusterJ applications would be considered, because they have direct access on the local privilege tables. |
![]()
|
The
pattern-name containers in the ACS tree window
The AclEntry uses the wildcard in the most complex cases. The MySQL Server ACS handles the wildcard characters '%', '_' and '§' in a container name. The name defines then a pattern for selecting the elements of the container. This way of naming is applied to some group names and some directory names. The character '%' replaces in MySQL Server any group of characters (and even no character). The character '_' replaces exactly one character in MySQL Server. On the other hand, the character '§' is specific to the ACS add-on. There are three types of pattern-name containers, as described following:
This last container is necessary for example to attribute one ACL to all the accounts 'jerry', 'jerry(2)' and 'jerry(z)' in all the current hosts. Such an ACL must have, as right user, a pattern-name accounts-for-hosts group. The name of this group is 'jerry§@%'. The ACS add-on sets its members as being 'jerry' and all the 'jerry(z)' accounts, excluding 'jerryOne' or 'jerry1'. The use of '§' is proper to the MySQL Server ACS addon. This ACS add-on models only the pattern-names having one wildcard. This is commented in the next section about the true MySQL Server behavior. |
![]()
|
The
virtual mixed AclEntry
The
mixed AclEntries are at the database level. The
term 'mixed ACL' is not from the MySQL Server documentation, but
it is useful for having a clear description. Mixed ACL are used
for simulating in Access Road the MySQL Server ' A mixed AclEntry is called virtual because it is never into the ACL list of a Resource. On the contrary, it is created through an internal processing of the current AclEntries on a database. Only a MySQL database may have mixed AclEntries. They are selected by the ACS addon. The main feature of an applicable mixed ACL is to be the last matched ACL on the database. The MySQL Server rule is: EXCLUSIVE OR (non-conditional user ACL on database AND non-conditional host (or hosts group) ACL on database). This means that each of these two real ACL do not deliver their rights directly to their right users, as for the other ACL. A full view never shows an access path having the form 'right user/non-conditional ACL for this right user/database'. A mixed ACL results then from the combination of two non-conditional ACL. The mixed ACL is produced by the ACS addon, not directly by the user, and it may appear in the full views. It appears as a special key in the primary rights map of the database. The resulting rights of the virtual ACL are the common rights of the two implied non-conditional ACL. The user's database-specific mixed ACL rights are computed as the intersection (not the union!) of the two non-conditional ACL rights lists. More precisely, if a non-conditional user ACL have no rights, it is not used to build up a mixed ACL. On the other hand, a non-conditional host (or hosts group) ACL having no rights may product an applicable mixed ACL with no rights. If all the AclEntries for the database-related rights (INSERT, UPDATE and so on) are at the database level, such a no-rights mixed ACL implies no rights for the pair (any right user from the host, resource). In this configuration, the mixed ACL is like a denying right for all the users of this host. When an access path finds a virtual ACL, the 'See why' text of the full view is completed by the comment: 'database mixed ACL through ' with the name of the host (or hosts group). |
![]()
|
The
MySQL Server oddities
The oddities of a simulated software is a classical section. An oddity appears when there is a lack of consistency among the software concepts, or into the behavior of the software. Our point of view is not to criticize a great software, but to learn and to simulate it precisely. Simulating is of course a powerful way to detect oddities, and we are happy to bring this information to the Access Road users. Sometimes, false information is published in varied supports about the access controls of a software. When we see them as common errors, they are listed in this section. The oddities and false information in the MySQL environment are extended to those beyond the MySQL Server, from usual tools like MySQL Workbench from Oracle, the editor of MySQL. They are listed hereinafter:
|
![]()
|
®All trademarks are property of their respective holders. Copyright ACCBEE – 02 May 2012 |
|