![]() ![]()
Access
Road 0.7.3
|
|
Creating
MySQL | Main properties |
Creating ACL |
Generic ACL
| MySQL
ACL
This second getting-started tutorial is for designing the access controls of a simulated software. It introduces the MySQL Server® modeling, as an example of design. If you have only 15 minutes for a simple reading, you may go to the last section 'Designing with Access Road'. It proposes 3 strategies based on the Access Road simulation to design the MySQL access controls. This is the most important tutorial of Access Road. It should be ridden by all the Access Road users. The first tutorial is recommended as a requisite. In an ideal world, the inner complexity of the access control features would be masked by Access Road. In the real world, this objective is fulfilled in the view diagrams of Access Road, but not in all the program. The inner complexity can never be oversimplified when the user wants to understand the results. Our commitment is to provide an exact simulation including all the required details. The user may choose to read only the diagrams, to put it simple, or to go further. To build up a thorough understanding of the issues and their solutions, we think the best approach is to provide in this tutorial some progressive explanations combining multiple points of view. This is both the Access Road way and the spirit that has guided the design of this present tutorial. There is no requisite about the knowledge of MySQL Server®, as a database management system, to follow this tutorial. We will discover together the Access Road generic features and a given simulation. However, this tutorial is a good start for exploring the basics of MySQL access controls. It explains the following actions:
The best way is to read this second tutorial twice: first as a simple reading, and then to operate on Access Road. The duration is estimated at two hours. At any time, you would stop the tutorial before its end. How to exit Access Road and save the current configuration is explained at the end of the first tutorial.
Creating a MySQL Server ACS
Run the Access Road program from the installation instructions. Close the central information box. If it is closed, open the ACS 'tubun' the first tutorial has created, through the command File → Open → Open Access Control System. The explorer and the beamer should remain open. If the beamer is closed, select in the main menu the command Window → Beamer. If some other windows are opened, close them by clicking the top cross of their windows. Note: closing a window may imply a saving only if it is a full view or a NoMore-NoLess view window. To create the out-of-the-box simulation of a MySQL 5 Server running on the 'Ubuntu' server, select in the main menu the command File → New → 'New Access Control system'. A window appears. Enter the name 'IO' for the ACS IS, the name 'sqyl' for the new ACS, select the first choice 'MySQL 5 Server', and click on the 'OK' button. A dialog selection appears about the parent. Click the node 'IO:: one:: tubun' then 'OK', to create the new MySQL Server under the node of the ACS 'tubun'. A second question appears to create a new component. Click 'No' then 'OK'. After a few seconds, the MySQL Server ACS 'sqyl' is creating in the base, saving in the working directory of Access Road, then it is opening and selecting in the explorer. Click the node 'sqyl' in the explorer. Following its structure, this new ACS has no nodes for the external components, but it has an additional node 'Virtual Folder for all (access target)'. A virtual folder is a folder of Resources, as a Directory. The relation virtual folder/member is weak, on the contrary of a Directory: deleting the virtual folder does not delete its members. A virtual folder is also a proxy node, since it may deliver some access to its members. The virtual folders are used by the MySQL ACS to model the MySQL views, which then are not Access Road views. Here is an example of why it is so important to well know the generic terms Access Road uses for all the ACS.
|
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
The 24 main structural properties
|
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
Creating a generic AclEntry
Let's see the generic ACL in the authorization subACS of the ACS 'tubun'. In the explorer, click the node 'IO:: one:: tubun:: <authorization_subacs>:: org:: gnome:: clockapplet:: mechanism:: set time zone:: '. In this authorization subACS, 'set time zone' is an action to attribute to Linux Ubuntu users through AclEntries. In the beamer, click the tab 'ACL', and for the first list at the top of the tab, click the button 'New'. This dialog window allows to create an AclEntry: ![]()
To enter the properties of the ACL:
We may note that the listed rights for creating this ACL was very different to the 'Ubuntu' AG rights we have seen in the previous tutorial. Some proposed values may not be truly authorized. The user would see an error message which explains clearly the issue. Note: the message is also displayed in the Java console of Access Road, but this has not to be considered as a bug. This new ACL enables the right 'authorize' to the UserID 'tom' for the target 'set time zone'. 'tom' may then change the time zone into this Linux Ubuntu operating system. The new AclEntry 'tom >> … set time zone || grant' is created and shown with this format in the explorer. 'grant' there means there this is a granting ACL. The opposite value is 'deny'. In the beamer, the property 'Right user (RU)' has for value the UserID 'tom'. An AclEntry may be managed by an ACS different to the ACS of the right user and/or different to the ACS of the resource, if the 2 or 3 ACS policies allow it. This has to be permitted by each implied ACS. We call such objects 'external AclEntries'. This is why the beamer tab 'General displays 3 distinct ACS names for an AclEntry. The beamer displays the tab 'ACL' where the effective right 'authorize' for this ACL is into the property 'List of rights'. With one or several condition groups, a generic ACL is called a 'conditional ACL'. It is disabled and it delivers no rights if the right user is not a direct or an indirect member of one of the condition groups. There are two kinds of conditional ACL: simple-conditional and right-conditional ACL (see the Access Road glossary to go further). These features are used by the MySQL Server® ACS and by the RBAC application ACS. In the beamer, click the back button, to go back to the previous displayed object. The beamer displays the 'set time zone' action. Its ACL list contains the new ACL. This ACL name is like into the explorer. The beamer displays also an 'ACL' tab for the Resources of the 'files_tree' Resources, but no ACL may be created there. This is a result of the ACS rights policy. By the same way, the node 'AclEntries: right user >> access target' appears in the explorer only for the relevant ACS. The explorer sorts the AclEntries by their ACL sources. It displays first the groups then the users. Note: this 'Ubuntu' ACS provides specific features on the Account/Group rights, like the 'umask' feature seen in the next tutorial, while it uses the generic ACL features of Access Road for its authorization subACS. In this section, we have seen an example of how the generic ACL are handled in Access Road. |
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
Handling the generic AclEntry
In the explorer, click the first AclEntry of the ACS 'sqyl', under the node 'AclEntries...', which starts with '<U>'. The ACL name is '<U>:: jerry:: >> MySQL server:: || grant || localhost'. The beamer title becomes 'Beamer: ACL jerry >> MySQL server'. An ACL name may have several presentations in the explorer, in the beamer, in a 'See Why' view text. In the explorer and the beamer, an internal ACL name is composed of:
For an external ACL, the procedure of creation is strictly the same. The format of the detailed name is as following: ACS: ACS_name | (full or incomplete) Eligible Party name >> (full or incomplete) Resource name || grant OR deny || <Source ACS group> OR <Target ACS group> || first condition group last component. An Eligible Party or Resource name is incomplete when the component belongs to the ACS of the AclEntry. The tag '<Source ACS group>' indicates the condition group belongs to the EligibleParty ACS, that is the source ACS. An ACL name does not contain the ACL rights, since they may change. This instance of ACL is conditional, with 'localhost' as first condition group, while the explorer shows another non-conditional ACL. In the beamer on this ACL, click the tab 'ACL'. In this 'ACL' tab, the property 'Enabled rights' is true. A non-conditional ACL simply grants or denies rights without condition group, and then, 'Enabled rights' is always true. As a generic concept, a conditional ACL enables its rights only if its right user (also called an ACL source) is member of all the condition groups of the ACL. The property 'Enabled rights' may then be true or false. This ACL is enabled because 'jerry' is member of the server 'localhost'. To display 'jerry': click on the beamer tab 'General' and the 'See' button of the first property 'Right User'. 'jerry' is selected, and its type is 'account'. Click on the tab 'Members'. The beamer shows a generic list named 'Is direct member of', where 'localhost' is the first item. To check this ACL, it is possible to use the sketcher : open the Sketcher with command Window → Sketcher (Ctrl+k). In the explorer, select the root Directory 'MySQL server'. The sketcher finds that 'jerry' has an 'USAGE' right which comes from this ACL. Unfortunately, the sketcher handles the simplest cases. It does not processes the inherited ACL, while they are the central part of the MySQL rights. For the root having no parent, it delivers a correct result, but not for the other MySQL Resources. This is the job of the full views we will see later. The root 'MySQL server' is now displayed in the beamer. Click the tab 'ACL'. The first property, entitled 'Sorted list for users 'account'...', displays the list of the direct AclEntries of any Resource. 'Direct ACL', here, is the opposite of 'inherited ACL' that is the role of the tab 'ACL Inheritance'. The property title is proper to the MySQL ACS, but it is a generic ACS property. Among other ACL, this list displays the ACL named: '<U>:: jerry:: >> MySQL server:: || grant || localhost'. The second list, in the same 'ACL' tab, shows all the right users into the direct ACL of the first list. In this second list, select the item 'IO:: one:: tubun:: sqyl:: <U>:: jerry::', and click the 'See' button. The beamer displays the same 'ACL' tab for the account 'jerry'. The list of Resources contains the ones on which 'jerry' has at least one ACL. The root 'MySQL server' is a target of one or several 'jerry' ACL. All the links between objects in Access Road are so managed and displayed into the beamer. |
|
Introducing the MySQL AclEntry
The account 'jerry' is member of 'localhost', and it is also logged to the server 'localhost' as its 'First host'. In the beamer tab 'Members' for the account 'jerry', there is a MySQL-specific property 'First host', having 'localhost' as value. For each new UserID, the MySQL ACS enforces the choice of such a first host. It is defined as the computer from which the account is logged on the MySQL server. All this explains why, through a conditional ACL, the MySQL user 'jerry' has the right 'USAGE' on the root 'MySQL server'. In the MySQL ACS, only one condition group is allowed to an account. This is not always true into another kind of ACS. Compared to the MySQL syntax, this conditional ACL indeed simulates a right statement on 'jerry@localhost'. The management of access controls by the MySQL server ACS may be summarized by 6 cases. This tutorial covers the 3 first cases. The other kinds of MySQL rights are introduced in the MySQL ACS addon documentation. The simulation of the MySQL Server access controls in this tutorial can take the following forms:
We will see now how these two kinds of ACL are summarized by the beamer, not as a generic ACL - we have already ridden it at the previous section. They are summarized to mimic the MySQL syntax for the right statements. To return to the root 'MySQL server', click the back button of the beamer. Click the tab 'ACL Inheritance'. We consider this node as the root from the semantic point of view, that is the root of MySQL Server access targets tree, since the node '|pattern-name_bases sets|' does not contain access targets. The second property in the tab is an empty sorted list, since the root has no inherited ACL. The third property, called 'Unsorted primary rights', is more interesting. We call primary rights in MySQL, the rights on a target before the selection of the applicable rights. Click, on the left list of the 'Unsorted primary rights...' map, the key 'IO:: one:: tubun:: sqyl:: <U>:: jerry@localhost:: 0::'. At right, the value 'USAGE' appears. As you may have noticed, this is another kind to display our well-known ACL, always the same old ACL 'jerry >> MySQL server', but there, it is possible to get its effective rights, and it uses a MySQL-friendly syntax! Getting the effective ACL rights means there is no key in this map if the ACL has no rights, or if it has disabled rights. For instance, the first ACL into the explorer (<G>:: anonymous§@%:: >> MySQL server:: || grant) does not produce any primary right, because this ACL has no rights. The 4 current keys of primary rights ends with '0'. This number means they come from the direct AclEntries of the current Resource 'MySQL server'. To compare the same list, Click the node 'BASE One' in the explorer, that is the first child of 'MySQL server'. The beamer displays a larger list, where:
This explains the title of this map: 'Unsorted primary rights at each parent level – The level is the key ending number'. For the Resource 'BASE One', the Resource 'MySQL server' is the parent having the level '1'. The primary rights map summarizes all the direct ACL on the current node – with a key ended with '0' - and all the ACL from any direct or indirect parent delivering some inherited AclEntries of the current node. This is an Access Road property to help the user. The term 'primary rights' is unknown in the MySQL Server documentation. The primary rights represent an intermediate level between the original ACL and the effective rights of a couple (right user, access target). By the way, it would also great for the user to have a look on how the MySQL server selects the applicable statements for a given couple (right user, access target). Let's study another list in this tab 'ACL Inheritance'. ![]() This is the sorted list of the inherited ACL on the base 'BASE One', from the parent 'MySQL server'. No ACL rights there, since the important thing is the order of the sorting. Click the beamer on the back button (to display 'MySQL server'), then on the tab 'ACL'. How strange. it is the same list! The direct ACL list on the root has been simply copied into this property of its child 'BASE One'. Click the tab 'ACL Inheritance', then, in the explorer, click the node 'Products table', the direct child of 'BASE One'. 'Products table' has a first sorted list where the 8 first ACL are also copied from the root 'MySQL server'. The 3 other ACL are copied from the direct ACL list of its direct parent 'BASE One', as it is visible in their names. The sorted list has the title 'matched ACL at each parent level: user@host or accounts-for-hosts or...'. This tries to recall the complex rules used for the selection of rights by the MySQL Server. First, about the term 'accounts-for-hosts' in the title of this sorted list of ACL, keep in mind that the groups 'jerry§@local%' and 'jerry§@%' have the type 'pattern-name_accounts-for-hosts group'. We will study the 'pattern-name' entities along with the Access Road full views. We introduce now the selection of rights. It is based on our well-known example. When the account 'jerry' requests an access to MySQL server, we see in the last list of ACL – remember they are coming from the direct ACL of the root – that it seems to have 3 matched statements for 'jerry':
Three selection rules are the ground of all the access controls into the MySQL Server. They take the following forms: MySQL Selection Rule 1: for a given level of parent, the MySQL server selects only one applicable right statement (one ACL in Access Road), and it is always the first one to match. Of course, the administrator cannot change the MySQL Server sorting rules on the right statements. This means, for this example, that the first sorted ACL 'jerry >> MySQL server' will deliver its rights to the account 'jerry' on 'localhost'. For this account, the two other ACL will never be used until the first ACL is deleted! The 'MySQL server' ACS provides a precise sorting of the AclEntries to simulate this MySQL Server behavior. MySQL Selection Rule 2: Global rights are on the root 'MySQL server' into Access Road. MySQL Selection Rule 3: for a couple (right user, access target), the MySQL server adds all the applicable rights at each parent level. This means the 'jerry' rights on, say, the target 'Products table', are simply the sum of the 3 sets of applicable rights on the root 'MySQL server', on the base 'BASE One' and on the target 'Products table'. The 'MySQL server' ACS handles the direct ACL and the inherited ACL to simulate this MySQL Server behavior. Note 1: to take account of the rule 2, when a right statement is set on any server component like a base or a table, as a help to the administrator, the MySQL Server and Access Road create automatically a global 'USAGE' right on the server, for the same couple (user, host), if there is no such right. Then, the new right statement becomes effective. Note 2: do not try to find these selection rules in the MySQL documentation. They are never presented into such a clear and short text... We thank you to have been very patient, learning MySQL rather Access Road! Now, by the way of the Access Road full views, these 3 MySQL rules will be illustrated quickly. |
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
Creating an Access Road full view
The full view is the main Access Road tool for simulating rights and relations between objects, to display and to explain them. A full view contains from 0 to 48 objects. The view objects are always coming from the open ACS. The aim is to detect all the access paths, if any, between each couple of objects in the view. The full view provides the functions to display the paths in two forms: a diagram and a text. An access path between two nodes is called simple or direct when there is no intermediate node. A path may be indirect with a number of intermediate nodes up to 40! The view text is the support and the reference to explain in details the results of the view diagram. For each access path, the text describes the nature of each link for each pair of connected nodes. ![]() In the main menu, select the command: File → New → 'New view'. The first dialog appears. Select 'Full view' then 'OK'.
![]() The second dialog appears to define the full view name. Enter the names 'sqyl' and 'jerry' in the two fields, then click 'OK'.
In the explorer, click the UserID 'jerry' and the 2 Resources 'MySQL Server' and 'BASE One'. If a selected object is both an EligibleParty and a Resource, it appears in the two relevant lists in the window. This is not true for these 3 objects. If you make an error, the button 'Remove in list(s)' should be used to deselect, for the new view, an object which is currently selected in the dialog window. When all is OK, click on the 'OK' button. The view 'jerry in the set sqyl' appears as a diagram in the right bottom coin of the main window. With the mouse, increase the size of the view window. In the view diagram, click the nodes, drag&drop them to obtain the following result: ![]() After the creation of a view, the explorer displays it as a node under 'Full Views'. The beamer displays its properties. They are very simple. The property 'Elements & comments' shows the ACS objects and the textual comments of the view. They are changed with the buttons 'Select' and 'Remove'. These items are also displayed in the explorer, under the view node. One can remark the view nodes are drawn with distinct patterns. There is one graphical pattern for each great type of ACS objects: UserID (like 'jerry'), Resource and Directory (like 'BASE One'), GroupID, VirtualFolder and Actor. The name of an object in the diagram is its name last component. It is not possible to separate for instance the node 'jerry' from 'tubun' to the node 'jerry' from 'sqyl'. This is why it is recommended to put the ACS name in the set name of the view. On the other hand, clicking the node in the view displays it in the beamer, to see all the details. All the access paths between each pair of view objects are detected. An arrow or a line between two view elements means there is one or several access paths between them. Nothing between 'BASE One' and 'MySQL Server' means that there is no access path. An arrow means the path is oriented, with a source and a target, so two nodes may be connected through two inverse arrows. An arrow or line is generally drawn with a text which explain very shortly the rights, or a general relation like 'owns', between the two objects. The rights may be ACS rights, as there, or generic rights. Into this view, the two arrows are similar because the two relations are from an UserID to a Resource. Note: Generally speaking, Access Road does not copy the internal algorithms of the software it simulates, whatever the software. This is impossible in numerous cases, since the simulated software does not model its concepts exactly like Access Road does. This is sometimes prohibit by law. Let's compare this full view to the sketcher. Use together the keys Ctrl+k to open the sketcher. An empty sketcher appears. Click the node 'jerry' in the full view 'jerry'. The numerous direct links around the UserID 'jerry' are displayed. This includes the two links in the full view, without the 'via' text about the indirect paths. In the view 'jerry', click on the node 'BASE one' (if necessary, move the window cursor to see the nodes at left). The sketcher shows 2 nodes above 'BASE one', including the UserID 'jerry'. The difference is the sketcher rights from 'jerry' to 'BASE one' are 'SELECT EXECUTE' without '<via> ...'. A full view shows all the access paths, as we will see, while the sketcher shows only the direct ACL, not the inherited ones. The sketcher is simply useful to have a look, and to jump from object to object through the network of simple relations. The explorer displays the types of ACS right for the MySQL Server. The greater rights are displayed first. Click the MySQL right 'SELECT' in the explorer. The beamer displays, for this right, the comments 'Authorize to SELECT rows on TABLE, COLUMN or VIEW', to summarize the meaning of 'SELECT' for the MySQL Server. This right may be applied to all the tables, columns and views of 'BASE One'. Access Road handles a full view only if all the ACS objects are from opened ACS. When the user closes an ACS, the open views having objects from this ACS are closed without view saving. In the same way, the closed views are checked when an ACS is removed definitely from the Access Road base. The view saving covers the list of the elements in the view, the location of the view diagram window and the 'See Why' window in the Access Road main window. The view saving keeps also the relative positions of the nodes in the view diagram. The opening of Access Road restores the last saving of the open ACS and the open views, with all the open internal windows like the IS Structure, the sketcher and the beamer. At the opening of a view, if a view element is from a closed ACS, a message informs the user and the view is not opened. The reading of a diagram is very intuitive. The objective is to offer a 'smart' reading to the eye. If there is an arrow from A to B and a second arrow from B to C, then this means, by default, there is an indirect access path from A to C. If such an indirect path is not true, the view has to inform the user. There is a simple drawing coding for the links into a diagram. They may use the following formats:
Note: The view diagram displays the right names as they are in the relevant ACS. There are few exceptions for some generic administrative rights, like for instance '|transfer_limited_rights|'. For these rights, the view diagrams display always the generic description of the right, and not the ACS-specific term, while the 'See why' text keeps the ACS-specific term. The views are fully independent. 2 views may have exactly the same items. Let's see now what is the 'See why' text of a full view, and what exactly means, in the view diagram, the term '<via>' in the text of an arrow. |
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
The 'See why' text
|
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
The updating of an Access Road full
view
We create now a second full view, for Linux Ubuntu objects, to make a quick test. First, we return to the display mode of independent windows for the full views: Close the 'Full views' window. A dialog appears to close all the open full views. Click 'No'. The view 'sqyl:: jerry' remains opened in the explorer. Follow the creation procedure of a full view, with 'tubun' as set name and 'any' as view name. Select for the view, in the explorer, exactly 12 'tubun' objects of your choice, including both UserID, GroupID and Resource objects. The user would see during few seconds a message 'Please wait', while Access Road detects all the access paths of the view. The new view diagram should appear as a unreadable network of links! Enlarge the diagram window, and try to drag&drop some nodes to get a clear presentation. An hidden grid defines the allowed positions of the nodes. If the number of links is too great, it is not easy to get a clear presentation. If a node is dropped on a location the diagram forbids, there is no move. Access Road uses for the full views a layout of the allowed locations that depends on the number of nodes. The range of locations is squares of 4x4, 5x5, 7x7 or 10x10 node locations. Up to 7 nodes, the view diagram uses a layout of 16 possible positions. A diagram of 12 nodes is displayed in a layout of 25 locations, while a 13-nodes diagram uses a layout of 49 possible locations. To have a better diagram, it is possible to enlarge the layout by an adding of object: Select in the explorer a new object for this view (if necessary, click in the explorer the view node 'tubun:: any'), and click into the beamer the 'Select' button of the property 'Elements & comments'. ![]() This dialog appears to add a view object or a comment. Select 'Object to select' then click 'OK'. A new dialog appears for a selection an object in the explorer. Select the object. The object of your choice is added at the top left of the diagram window. It is recommended to move any new node immediately, to let empty this place for the future additions. The good new is Access Road has just selected a layout of 49 locations for this diagram. The nodes would be more easy to be well positioned, getting a clearer network of links. To try to clarify the diagram, enlarge the view window and try to drag&drop some nodes to the bottom of the diagram. Of course, if the number of links is too great, the diagram will stay unreadable, even if the 'See why' text is always workable. The best choice is then to get less nodes in the diagram. The view may be cut in two complementary views. Note 1: When a view node is removed, the positions of the other nodes may change into the full view diagram, because the layout has also changed. Note 2: A new view node is added at the top left coin of the diagram, but sometimes it is not alone. It is necessary to add a second element when there is a hard alias relation. An example is a MySQL view, which is modeled as an Actor being alias of a Virtual Folder. When the user adds to a view one of these two components, the second element is automatically added by Access Road in the bottom right coin of the full view diagram. Save your current work through the command File → Save All (Ctrl+s). Close the diagram of the second view 'tubun:: any'. Click 'Yes' in the dialog window, to close this view. We will discover now one of the most powerful feature of Access Road. It updates immediately an open view at any change in the base which modifies the results of the view. This is true for example when the rights change in any implied ACL, or when an UserID is no more member of a GroupID. We use the first view 'sqyl:: jerry' to test the MySQL selection rules. For a given level of parent, the MySQL server selects only one applicable right statement (one ACL in Access Road), and it is always the first one to match. The idea is to delete the matched global ACL 'jerry >> MySQL server', to see how the rights change in the view. An ACL is created and deleted through its target ('MySQL server' here). In the explorer, select the first view 'sqyl:: jerry', then use the command Window → View diagram or ACS tree (Ctrl+u). The diagram and the 'See why' text are opened. Click in the view diagram the node 'MySQL server', then in the beamer, click the tab 'ACL'. Into the sorted list of ACL, select the ACL from 'jerry' ('<U>:: jerry:: >> MySQL server:: || grant || localhost'). Click the list button 'Delete'. Confirm the command. When the view has very complex paths, the updating of the access paths may need several seconds. The user has a message in Blue 'Please wait...' at the top left coin of the diagram. But this should not be here. The view 'sqyl:: jerry' is updated, both its diagram and its 'See why' text. In the diagram, deleting the ACL has replaced the direct rights 'SELECT' and 'EXECUTE', from 'jerry' to 'BASE One'. Here is the updated 'See why' text: ![]() The resulting text is fully changed. The rights of 'jerry' on 'BASE One' is now CREATE (it includes USAGE). The current user is no more (jerry, localhost) but (jerry, jerry§@local%). CREATE is delivered by a direct ACL on 'BASE One': '<G>:: jerry§@local%:: >> MySQL server:: BASE One:: || grant'. It is easy to check it through the beamer, when 'BASE One' is selected in the explorer, as we have seen in the section 'Introducing the MySQL Server AclEntry'. Note: when a global right statement is deleted, the MySQL Server deletes all the similar statements at the other levels. This behavior is reproduced by the 'MySQL server' ACS. This is why deleting the global ACL 'jerry@localhost' has produced a deleting of the second ACL 'jerry@localhost' on 'BASE One'. Reading a diagram is very intuitive. An important property is to offer a 'smart' look to the eye. Whatever the choice of elements in the view, the overall meaning has to be stable. Let's take an example. The new rights are get through the strange group 'jerry§@local%'. What about the diagram, if this group is added to the view? ![]() Click in the explorer the view 'sqyl:: jerry'. In the beamer, on the property 'Elements & comments', click the 'Select' button, click 'Object to select' in the dialog box, then click in the explorer the 'sqyl' GroupID 'jerry§@local%'. The view is updated. Enlarge the diagram window and move the nodes to get this result. Each path is commented with a text starting near the source of the path. There are 2 inverse paths between 'jerry' and 'jerry§@local%'. The text 'member of' is near 'jerry', so 'jerry' is the member of the group. The first look shows no link between 'jerry' and 'BASE One'. However, 'the user eye' may find an indirect path, because 'jerry' is member of 'jerry§@local%'. A membership, as the other structural relations, is shown with a blue line rather than an arrow. 'jerry§@local%' has a CREATE right on 'BASE One' (this is a black arrow). Then, 'jerry' has a CREATE right on 'BASE One'. With or without the group 'jerry§@local%' in the view, the overall result is exactly the same. The last state of the view shows us a new property of MySQL Server for a pattern-name group like 'jerry§@local%'. This GroupID contains automatically and uniquely all the accounts having a name with the form 'jerry' or 'jerry(x)' (whatever the character 'x'), and belonging to any host having a name with the form 'local%'. '%' is for MySQL Server a wild-card meaning 'any sequence of characters'. This is why 'localhost' matches as a host. The 'See why' text describes the link from 'jerry§@local%' to 'BASE One' without current user, because it may be used by any member of this group, and not only by 'jerry'. Note: if you know how MySQL Server works, you may remark the group 'jerry§@local%' is the equivalent to the MySQL right statement 'jerry@local%'. The difference '§' is specific to Access Road, to ensure an account has only one first simple host. There is a strange path from 'jerry@local%' to 'jerry', in other words, from a GroupID to an UserID. The diagram shows the text '<via> inti contxt' for this path. How a GroupID could have an access path to an UserID? In the glossary, the term 'init contxt' is explained like this: “In a view, when there is an access path to an Actor starting under a given UserID or GroupID context, this actor runs under this UserID or GroupID, as component of the proper Account/Group context of the Actor. A relation 'Run under' is created in the view from the Actor to the relevant Account (in other words, UserID) or GroupID. This relation is displayed in the view diagram as a line with the comment 'init contxt' (for 'initial context'). When an Actor is executed directly, its default AG context is overridden by the received AG context into the access path. However, for some specific cases, the current AG context of the path may be switched to the Actor default AG context. As a generic behavior, this default AG context is applied only when the Actor is the first end of an access path, or when it receives a call through its ExchangePoint. The specific cases are found among the ACS addon Actors, like ExecutableUbuntu in the ACS addon Ubuntu, or the DEFINER mode in the ACS addon MySQL.” We have here 2 examples of the DEFINER mode of MySQL, for a trigger and a stored procedure (2 kinds of MySQL Actors). This means it is possible, for a member of the GroupID 'jerry@local%', to get a kind of execution in the context of the UserID 'jerry'. Of course, this execution is controlled by the Actor that is the intermediate node in the path. The 2 paths from 'jerry@local%' to 'jerry' are described into the 'See why' text as, in a condensed form: jerry@local%/ acl/ trigger_one/ runs_under/ jerry, and jerry@local%/ acl/ procedure_one/ runs_under/ jerry. How is the diagram if the 'natural' indirect path through a node is indeed forbidden? If there is a direct path from 'jerry' to 'BASE One' that forbids the current indirect path via 'jerry§@local%', then this direct path is drawn in a double-length-line arrow. It is then the only applicable path. To see such a simple unique path, let's return to the previous state of 'sqyl'! Create the new ACL 'jerry@localhost' on 'BASE One', with the rights SELECT and EXECUTE. The procedure to follow is from the first tutorial. Simply keep in mind that the right user to select is 'jerry', and 'localhost' is the conditional group to choose (caution: a 'jerry' ACL without conditional group may be created on the directory modeling a MySQL base, but the result in the view would be different). ![]() The 2 double-length-line arrows forbid the indirect paths. This means 'jerry§@local%' can no more be an intermediate node from 'jerry' to access to 'BASE One' or 'MySQL server'. On the other hand, this group keeps its own accesses, and some of its members, except 'jerry', may have to use them. In a such a case, the 'See why' text displays, for the paths from 'jerry' to 'BASE One' and the path from 'jerry' to 'MySQL server', a special comment 'Global <first rate link>' in the first simple path. It is the equivalent of the double-length-line arrow in the diagram. Save your current work through the command File → Save All (Ctrl+s). To design access controls for the MySQL Server, we cannot simply read a full view and take the results without question. We have to master the rights sorting and the rights inheritance management. Access Road is there to help you. |
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
About the MySQL Server design
This tutorial does not study the MySQL Server privileges with the vocabulary of MySQL Server. Its purpose is to handle the MySQL Server access controls with the vocabulary of the MySQL Server ACS addon, into Access Road. To connect the concepts of the two worlds, let's see the guide for this ACS addon. In the next section, we will see how to use the full views to define and verify the design of the rights on a MySQL Server. There is already a powerful and well-known free software called MySQL Workbench®. It is able to design the access controls through administrative and technical roles. Above all, it can inject the resulting design, as right statements, into an instance of MySQL Server. For instance, it is quite easy to design, with MySQL Workbench:
For simple and stable needs of access controls, MySQL Workbench is quite good. It is efficient for managing the administrative roles. However, this tool has some important limitations each time the MySQL Server contains complex or unstable bases, or with fine-grained needs of access control. It does not cover the full range of the MySQL access control features:
Furthermore, MySQL Workbench does not permit flexible strategies of access control. On the other hand, Access Road is able to simulate all the strategies. |
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
Designing MySQL Server access
controls
|
![]()
One-hour tutorial for learning access controls
Three-hours tutorial for verifying access controls ![]()
|
Creating
MySQL | Main properties | Creating
ACL | Generic
ACL | MySQL
ACL
Creating full view | 'See
why' text | Full
view updating | MySQL
design
Designing
with Access Road
®All trademarks are property of their respective holders. Copyright ACCBEE – 20 February 2013