Access
Road 0.7.1 Designing 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
This
getting-started two-hours tutorial is for designing the access
controls of a simulated software. It introduces the MySQL Server®
modeling by Access Road, using it as an example of design. If you
have only 15 minutes for a simple reading, you may switch to the
last section, where the design of MySQL access controls is
explained.
This tutorial should be
ridden by all the Access Road users. The first tutorial about
learning access controls is a requisite. The best way, which is
not a waste of time, is to read it twice: first as a simple
reading, and then to operate on Access Road.
This is the most
important tutorial, even if it may appear not very easy. In an
ideal world, the inner complexity of the access control features
would be masked by Access Road, to help the user. In the real
world, this inner complexity can never be oversimplified, since
our commitment is to provide an exact simulation. Furthermore, to
help the user to build up a thorough understanding of the issues
and their solutions, it is proved that extended explanations and
multiple points of view are the best approach. This is both the
Access Road way, and the spirit that has guided the design of
this present tutorial.
To follow this tutorial,
there is no requisite about the knowledge of MySQL Server®
as a database management system. We will discover together the
Access Road generic features and a given simulation. This
tutorial explains the following actions:
creating an Access Control
System (ACS) which simulates MySQL Server 5,
creating a full view to see
the access paths between some modeled objects,
handling the view main
window, the view 'See why' window and the 'Full Views' window,
handling the generic
AclEntries and the MySQL Server AclEntries,
understanding the varied
relations among the objects in a view,
using these features to
discover the MySQL Server access controls, as an example of the
help Access Road brings to design.
This tutorial is a good
start to understand the basics of MySQL access controls.
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 this
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.
To create the
out-of-the-box simulation of a MySQL 5 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 Linux Ubuntu 'tubun'. A second question appears to create a
new component. Click 'No' then 'OK'.
The MySQL Server ACS
'sqyl' is created, opened and selected in the explorer.
You should have the
opening of at least two internal windows: the explorer at the top
left, and the beamer at the top right. If the beamer is closed,
select in the main menu the command Window → Beamer. If
other windows are open, close them by clicking the
top cross of their windows.
The explorer shows for
'sqyl' an additional node which is not displayed for 'tubun'.
This is 'Virtual Folder for all (access target)'. A virtual
folder is a folder of Resources. The relation virtual
folder/member is weak, on the contrary of a Directory, and this
means deleting the virtual folder does not delete its members.
Virtual Folders are used by the MySQL ACS to model the MySQL
views, which then are NOT Access Road views! This is why it is so
important to know the generic terms Access Road uses to designate
the common concepts for all the ACS.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The 22 ACS main structural
properties
in Access Road
In the beamer displaying
'sqyl', click the tab 'Structure' to have a first look
on the properties of this ACS. You should have the following
result:
The
ACS tab 'Structure' shows the 22 booleans which define the
main structural properties of an ACS into Access Road. To
discover an ACS, it is a good idea to have a look first on its
'Structure' tab. There is a complementary tab 'Structure 2' in
all cases. There is a 'Structure 3' tab when the privileges or
the virtual folders are managed, like here. Some ACS addon may
provide an additional 'Structure 4' tab. The tab 'Context' is
reserved to the relations with the other ACS in the information
system.
Let's compare the ACS
structures of the Linux Ubuntu 'tubun' and the MySQL Server
'sqyl'. The beamer remembers the last selected tab, and tries to
select it for the next selected object in the explorer. It is
easy to switch to another 'Structure' tab: in the explorer,
click the node 'tubun', then on the node 'sqyl', and repeat.
There are common
properties to 'tubun' and 'sqyl', like the first four booleans.
There are also great differences. 'Account and Group Rights',
'Right-condition ACL', 'Bridges' and 'AG rights inheritance' are
properties the MySQL Server ACS does not manage. On the other
hand, 'Simple-condition ACL', 'Account Group Trees', 'Virtual
Folders', 'ACL inheritance' and 'Hard Aliasing' are properties
which are managed by the MySQL Server ACS. In this tutorial, it
is not necessary to understand fully all these properties. The
preferred way is a gradual learning along the tutorials. If you
are very curious, the beamer provides a tip for each of these
terms, and they are defined in the Access
Road glossary.
To summarize, the MySQL
Server ACS manages Resources, Directories, UserIDs and GroupIDs,
just like 'tubun'. It does not have Account/Group rights, but it
has an extended use of AclEntries, simple-condition AclEntries
and ACL inheritance in the Resources tree. AclEntries are indeed
for modeling what MySQL Server calls 'privileges'.
The Access Road
privilege rights, which are among the 22 boolean ACS properties,
are NOT implied to simulate the MySQL Server privileges! The
reason is of course the (lack of) matching between the semantic
of each concept, but this is beyond the scope of this tutorial.
Virtual folders and hard aliasing are necessary to simulate the
so-called MySQL Server views.
Unfortunately, this
ambiguity in the vocabulary is impossible to avoid. The rich set
of terms in the generic vocabulary of Access Road is necessary to
try to model a large scope of software. This vocabulary cannot
match the terms of every specific simulated software.
Nonetheless, to help the association to the true MySQL terms,
each MySQL Server virtual folder in Access Road has a name which
ends with 'view'. For the MySQL privileges, this is not useful.
The AclEntries has no proper names in Access Road, and by the
way, there is no privilege name in MySQL Server.
The ACS main properties
drive the choice of the nodes the explorer displays. Click
the explorer nodes of 'sqyl' to get the following image:
As components, the
MySQL Server is modeled mostly as: - a tree of components
in one or several bases like 'BASE One' in the Resources
tree, - (new in 0.7.1) a set of Actors as entry points for the
external accounts in the 'connection' subACS, - a tree of
MySQL views which contains some components (the virtual
folders), - a set of users (UserID), - a tree of
groups which are displayed twice, one time located in a
subACS tree called 'standard' with strong patterns on names
(GroupID), - a set of AclEntries (ACL) from the users
or groups to the resources.
The ACS 'sqyl' manages simple-condition AclEntries to simulate
the MySQL privileges. In the ACS addon 'MySQL Server', the
simple-condition ACL is mainly a conditional ACL which delivers
rights to the pair (user@host). MySQL handles this couple to name
a MySQL user logged in a given host.
Since virtual folders are right users, they are created in 'sqyl'
through the property 'Right-User VFolders', in the tab 'Right
Users' of this ACS.
As a processing, the
core of the MySQL Server simulation is the management of the ACL
sorting, the ACL inheritance and the pattern-name containers
under the nodes '|pattern-name_bases sets|' and
'<standard_tree>'.
An
ACL on a Directory is inherited by all its direct and indirect
children, and even by other resources if it is on a pattern-name
bases set. There are complex rules about the applicable
AclEntries for a given couple 'user@host'. There are some
oddities about the delivering of rights by an ACL.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Creating a generic AclEntry
To understand the rights
simulation, let's see the generic ACL for the authorization
sucACS into 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 appears.

To enter the properties of the ACL to create:
Click
on the button 'Select_1'. A
window 'Selection' appears. Click the node ACS
'tubun', in the explorer. 'tubun'
appears in the first field 'ACL manager'.
Click
on the button 'Select_2'. A
window 'Selection' appears. In the explorer,
open the node 'UserIDs (right user)', then click the UserID
node 'tom'.
Click
on the button 'Select_3'. A
'Selection' dialog shows 5 rights to select in a list. Click
on the third right 'authorize', then click 'OK' into the
Selection window.
Do
not click the button 'Select_5'. Then,
this property remains null, while its name indicates to the user
this is allowed.
Click
on the button 'OK' into the 'Create a new ACL' window.
The new AclEntry 'tom >> set time zone' is created. The
explorer and the beamer display it. We may note that the rights
Access Road has listed for creating this ACL was very different
to the AG rights in the previous section. In complex cases, some
entered values are not truly authorized. The user sees then an
error message which explains clearly the issue.
This
new ACL enables the
right 'authorize' to the UserID 'tom' for the target 'set time
zone'. This means
'tom' may then change the time zone into this Linux Ubuntu
operating system. In the beamer, the ACL is shown, and the
property 'Right users in ACL' has the value 'tom'.
The
property 'Condition groups' has been set to null for this new
ACL, because it is not conditional. Otherwise, this dialog allows
to select the first condition group.
With condition group(s), the ACL is disabled and it delivers no
rights if the right user is not a direct or an indirect member of
one of the condition group. There
are two types of conditional ACL. This feature is used for
instance by the MySQL Server®
ACS addon, in the next tutorial,
and in the RBAC application ACS. The condition groups list has to
remain empty there, since they are not managed by the Linux
Ubuntu ACS addon.
An
AclEntry may be managed by an ACS different to the ACS of the
right user and/or the ACS of the resource. This has to be
permitted by each implied ACS. We call such ACL external
AclEntries.
In the beamer, click
the back button, to go
back to the previous displayed object. The
beamer displays the 'set time zone' action, and its ACL list
contains the new ACL. This ACL name includes there the name of
the ACL source and the name of the ACL target, like into the
explorer. We may see that the beamer displays an 'ACL' tab only
for the Resources of the authorization subACS, and not for the
'files_tree' Resources. 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. For other ACS, the
explorer may display other standard nodes the Linux Ubuntu does
not handle, like when there are privileges or external ACL, for
instance.
We
have seen there an example of how
the generic ACL are handled in Access Road. One
could be astonished to see a generic handling of ACL in an ACS
addon like Linux Ubuntu. In fact, this ACS addon provides
specific features on the Account/Group rights, while it simply
uses the generic ACL features of Access Road into the
authorization subACS.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
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
ACL name is
composed of:
'<U>::
jerry:: ' there, is the ACL right user name, but an
internal ACL shows only its two last components to be concise,
'>>'
to separate the right user to the access target,
'MySQL
server:: ' there, is the ACL target name, but an internal
ACL shows only its last components after the ACS name,
'||'
to separate the sens,
the
ACL sens may be 'grant' or 'deny',
and
if necessary, '||' to separate the optional group,
'localhost'
there, is the first ACL condition group, if it is a
simple-condition ACL or a right-condition ACL.
For an external ACL, the format of the detailled 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, which 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 tab, the property 'Enabled rights' is true, and it is
important to understand why. 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 our 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 Resources. This is the job of the
full views.
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'
there is the opposite of 'inherited ACL'. The property title is
proper to the MySQL ACS, but it is a generic ACS property. This
list displays of course the ACL named:
'<U>:: jerry:: >> MySQL
server:: || grant || localhost'.
The second list, in the same 'ACL'
tab, shows all the right users into these direct ACL. In this
list, select the item 'IO:: one:: tubun:: sqyl:: <U>::
jerry::', and click the 'See' button. The beamer displays
the same 'ACL' tab for 'jerry'. The list of Resources contains
the root 'MySQL server' as 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 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 ACS. Compared to
the MySQL syntax, this conditional ACL simulates a right
statement on 'jerry@localhost'.
The management of access controls by the MySQL server ACS may be
summarized by 6 cases. To put it simple,
this tutorial will cover only the three first cases. The
other kinds of MySQL rights are covered by the MySQL ACS addon
documentation. The simulation of the MySQL server access control
in this tutorial can take the following forms:
the
ACL source is a proxy
having
no proper rights, using the rights of a proxied account as user;
setting
rights of the user to the pair (user@host), through GRANT
statements without
wildcard into the names,
at the global (like this first ACL), database, table, column and
routine levels, and this is simulated by a conditional
ACL for an account;
setting
rights of the user to the pair (user@host with wildcard) through
GRANT statements with a wildcard
'_' or '%' only into the host name,
at the global, database, table, column and routine levels, and
this is simulated by a non-conditional
ACL for an 'accounts-for-hosts' group,
like the first displayed ACL into the explorer: '<G>::
anonymous§@%:: >> MySQL server:: || grant;
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 - but rather as an
object that mimics 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'. The second property is an empty sorted
list, since the root has no inherited ACL. The third property,
called 'Unsorted primary rights', is more interesting.
Click, on the left side 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 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 displayed ACL into
the explorer (<G>:: anonymous§@%:: >> MySQL server::
|| grant) does not produce any primary right, because this ACL
has been created with no rights at all.
The 4 current keys of primary
rights ends with '0'. This indicates simply they come from the
direct ACL of the current Resource, the root MySQL server. To
compare the same list, Click the explorer on the child
'BASE One'. The beamer displays a larger list, where:
the 4 previous primary rights are
included, but ending with '1' rather than '0',
2 other primary rights ends with
'0'.
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 a parent at the level '1'. The
primary rights map summarizes all the applicable ACL on the
current node – with a key end at '0' - and from any direct or
indirect parent delivering some inherited AclEntries.
This is an Access Road property, so
the term 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 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'. Click the beamer on the back button (to display
'MySQL server'), then on the tab 'ACL'. 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', direct child of 'BASE One'. 'Products table' has a
sorted list where the 8 first ACL are also copied from the root
'MySQL server', and the 3 other ACL are copied from the direct
ACL list of its direct parent 'BASE One'.
The list has the title 'matched ACL
at each parent level: user@host or accounts-for-hosts or...'. It
tries to recall the rules used for the selection of rights by the
MySQL Server. First, to
understand 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':
<U>:: jerry:: >> MySQL
server:: || grant || localhost,
<G>:: jerry§@local%:: >>
MySQL server:: || grant,
<G>:: jerry§@%:: >>
MySQL server:: || grant.
Three rules are the ground of
all the access controls into the MySQL Server. They take the
following forms:
MySQL
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 addon provides a precise sorting
of the AclEntries to simulate this MySQL Server behavior.
MySQL
Rule 2:
the
MySQL rejects the connection of an account if it has no
applicable global rights (that are on the root 'MySQL server'
into Access Road).
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).
MySQL
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'. Again, the MySQL server ACS addon handles the
direct ACL and the inherited ACL to simulate this MySQL Server
behavior.
Note: the first rule is correct for
the 3 first forms of rights, which are those this tutorial
covers. It has to be adapted for some of the 3 other cases. The
second rule is correct for the 5 last forms of rights, but not
for the first one. The third rule is correct for the 6 forms of
rights the MySQL Server handles.
Well, at this step of the tutorial,
we have to thank you to have been patient, learning MySQL rather
Access Road! Now, by the way of the Access Road full views, these
3 MySQL rules will be illustrated much better.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Creating an Access Road full view
The
full view is the main Access Road tool for simulating rights and
relations between objects.
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 is called
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 couple of intermediate
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'.
The
third dialog appears to select the initial objects of the new
view. The 3 empty lists are respectively for displaying the
EligibleParties, Resources and VirtualFolders the user has
selected in the explorer.
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, but it is not
the case for these 3 objects. If you make an error, the 'Remove
in list(s)' button should be used to deselect, for the 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 node 'MYSQL SERVER' at
right, and drag&drop the node to move it and obtain the
following result.

After the creation of a view, the explorer selects it as a node
under 'Full Views'. The beamer displays its properties. They are
very simple. The property 'Elements' displays the view elements.
It allows to change them through the buttons 'Select' and
'Remove'. These elements 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'), Resources (like 'BASE One'),
GroupID, VirtualFolder and Actor. The name of an object in the
diagram is just its name last component, so 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.
All
the access paths between each couple of view objects have been
detected and displayed by Access Road.
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 or line is
generally drawn with a text which explain very shortly the
rights, or the relation, between the two objects. The rights may
be ACS rights, as there, or generic rights. The two arrows are
similar in this view, because the two relations are from an
UserID to a Resource.
Note: Generally speaking, Access
Road does never copy the internal algorithms of the software it
simulates. This is technically impossible in most cases, since
the simulated software does not model its concepts exactly like
Access Road does. This is also difficult in practice, and even
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
on the node 'jerry' in the full view 'jerry'.
The
direct links around the UserID 'jerry' are displayed, and this
includes the two links in the previous full view. In
the view 'jerry', click
on the node 'BASE one'.
The
sketcher shows 2 nodes above 'BASE one', including 'jerry'. The
difference is the sketcher rights from 'jerry' to 'BASE one' are
'SELEC EXECU' without '<via> ...'. A full view shows all
the access paths, as we will see, while the sketcher shows there
the direct ACL, not the inherited ones.
The explorer displays the types
of ACS right for the MySQL Server. It displays the ACS rights
from the greater ones. Click the right 'SELECT' in
the explorer. The beamer
displays, for this right, the comments 'Authorize to SELECT rows
on TABLE, COLUMN or VIEW' to explain the meaning of 'SELECT' for
the MySQL Server. This right is then applied to all the tables,
columns and views of 'BASE One'.
Access Road handles a full view only if all the view objects are
in open ACS. This rule is enforced by Access Road, which informs
the user about any issue. When the user closes an ACS, the open
views having objects from this closing ACS are closed by Access
Road 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 covers 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 or removed ACS, a message to
the user is displayed and the view is not open.
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 there is an indirect access path from A to
C. But such an indirect path is not always true. This is an
example which justifies the need of a simple drawing coding for
the links into a diagram. The links between two nodes in a
diagram may use varied formats:
a
black
arrow
is
an usual format for displaying the rights,
a
blue
line
indicates
a structural link, like for instance when an UserID is member of
a GroupID,
a
dashed-line
arrow
indicates
a weak link ('<WEAK> in the 'See why' text'), and this
means the context of this link is not complete, like for
instance when a GroupID has rights on a Resource, while its
applicable rights are never used without the knowledge of the
associated UserID,
a
double-lenght-line
arrow
indicates
the opposite of a weak link, and this means the effective
relation between the two nodes is the direct one, while all the
indirect paths does not deliver false structural relations, but
deliver false rights.
Note:
In most of the cases, the view diagram displays the rights names
as they are in the relevant ACS. There are few exceptions for
some generic administrative rights, like for instance the
generic right '|transfer_limited_rights|'. It is the reference of
the MySQL right 'GRANT ALL'. This is why, if this MySQL right has
to be displayed in a full view diagram, it is replaced by the
term '<grant to second>'. The glossary
defines this case as when the rights owner may delegate to a
second owner all the non-administrative rights he gets, excluding
his administrative rights like this one. For these important
administrative 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.
Let's see now what exactly means, in the view diagram, the term
'<via>' in the comments of the two arrows, and above all,
what is a 'See why' text.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The 'See why' text
of an Access Road full view
A
powerful feature of a full view is its ability to explain all the
access paths. The
'See why' window displays
all
the access paths Access Road has found into a view.
In the view
'jerry', click
on the 'See why' button.
A new window
'sqyl:: jerry:: 'See why' text' appears. Access Road generates
this text following a precise form. The middle of the text is
displayed hereinafter. We analyze it in details.
Each arrow or line in the view diagram is commented in a section
which starts with 'FROM A RIGHT USER TO AN ACCESS TARGET'.
Most of the visible text is
about the relation from 'jerry' to 'BASE One'. Both names are
written in blue.
The generated text informs us there are 3
access paths, numbered from 1 to 3.
The first access path
is direct. It is an ACL link which gives the rights SELECT, USAGE
and EXECUTE. This path explains the main result in this view and
in the sketcher, for the couple (jerry, BASE One). One may remark
the rights for the couple (jerry, MySQL server), into the direct
access path, are quite different, with only USAGE.
It is
useful to study this first path, which indeed contains a range of
information in a condensed form:
ACL: there is an ACL
relation; an access path may contains several relations,
(SELECT EXECUTE: this is
the rights from the direct ACL on the link second end (the
access target 'BASE One', there, since it is a direct path),
Current User: (jerry,
localhost): this tells 'jerry' is logged under this couple
(user, host); the MySQL server should for example attribute
(jerry, %) as the current user under which 'jerry' get its
rights (the term of 'current user' is from MySQL),
<inherited ACL> USAGE:
this is the right(s) get from the inherited ACL on the link
second end 'BASE One'; it is of course from a root ACL, since
'MySQL server' is the only parent of 'BASE One', but a link may
show inherited ACL from indirect parents,
<conditional ACL> through
localhost): this tells some of the direct or inherited ACL
are conditional ones using 'localhost' as condition group;
several condition groups are possible for MySQL, through several
conditional ACL,
-- All Rights:
SELECT/USAGE/EXECUTE: this summarizes all the applicable
rights; the main interest is when there are positive and
negative rights to subtract, but this is not possible into the
MySQL server ACS.
This range of information is mainly provided by the generic
features of Access Road. The MySQL Server ACS addon adds in this
'See why' text two items: Current
User: (jerry, localhost) and
<inherited
ACL> USAGE.
The rights are consistent in the diagram view and the 'See why'
text. However, the diagram cannot displays all the rights if the
words are too large, and the diagram displays the sum of the
rights, not the list of all of them. This is why the diagram
displays, for this link, 'SELECT EXECUTE' without 'USAGE', which
is contained into the two visible rights. The pattern '…' in
the diagram tells there is no place to write the last rights in
the diagram. It displays also '<via>', and this means there
is at least one indirect access path.
The
second path from 'jerry' to 'BASE One' contains 2 intermediate
nodes: 'function_one'
and 'tom'. Between
each pair of nodes in the path, there is a numbered link, like
'Link number 2: Runs Under' from 'function_one' to 'tom'.
In this second path from the account 'jerry', some rights are
delivered through another account 'tom'. In the link number '1'
of the second path, the generic comment '<Sets Owner>'
indicates there is a switch under the Account/Group context of
the Actor 'function_two': 'tom' is the UserID under which
'function_one' runs as a stored function. This means that the
initial current user 'jerry@localhost', with the MySQL syntax,
has the rights to execute 'function_one', and this stored
function runs under the UserID 'tom' which delivers to
'function_one' some ACL rights on the base 'BASE One'.
In a very condensed form, this second path may be represented by
the expression 'jerry/ acl/ function_one/ runs_under/ tom/ acl/
BASE One'. This is indeed the simulation of the so-called DEFINER
mode into MySQL Server. It is supported by a generic feature of
Access Road, able for example to simulate, in a Linux Ubuntu, the
behavior of a program starting under a given Account/Group
context. An another example is the capability to find all the
programs which, from a given UserID, allows to run into the
context of a privileged UserID.
It
may seem strange to declare that 'function_one' has rights on
'BASE One', while we don't know what this function done, and it
may never use these rights. Generally speaking, Access
Road simulates what the software MySQL Server 'knows' about
access controls, and
not the effective executing paths and data access. A very good
precaution in IT security is to not have confidence on any
program without serious thought, to not suppose it makes only and
strictly what it is supposed to do, like 'function_one' there.
Save
your current work through the command File → Save All (Ctrl+s).
The 'See why' text may be
selected and copied into the desktop operating system native
clipboard, to be exported into any application. We display now,
in the Access Road main window, a view diagram window and a 'See
why' window for the full view 'sqyl:: jerry:: '. It is possible
to open several full views, and to group them in one window:
Select in the main menu, the command Window -> All
Full Views (Ctrl+m).
The two full view windows
disappear, and they are replaced by a central
tabbed 'Full Views' window.
Each open view is displayed in a tab with the same diagram at the
top, and the same 'See why' text at the bottom, but without
colors.
An open view in the GUI is seen in the explorer. It may be
without displayed diagram nor 'See why' text. This allows to open
numerous views without filling the main window uselessly. When
the menu command 'View diagram or ACS tree' is used while an open
view is selected in the explorer, it is placed in a new tab of
the 'Full view' window if it is open in the GUI. Otherwise, the
diagram is put in its own view main window, like our first
example at its creation. In all cases, the diagram and the 'See
why' text of a view may be closed while the view remains open in
the explorer.
Let's
now have a look on how the 'See why' text describes the access
paths, whatever the ACS, as varied relations or rights. As 'ACL'
there,
'Runs Under', 'Is Member', 'Owns', 'Contains' and 'AGO Other
rights' are varied link types among others. The point is the link
type tells what
object properties to consult in the beamer to
study a relation or a right.
In the explorer or the view,
click 'BASE One', then in the beamer, on the tab 'ACL
Inheritance'.

The image shows the primary rights
map of 'BASE One'. The selected key ends with '0'. It explains
then the rights get from the direct ACL on 'BASE One', as the
view has found them. Finally, this study of the 'See why' text
demonstrates how an Access Road view fulfills with the 3 basic
MySQL rules about access controls, as they are presented in the
section 'Introducing the MySQL ACL'.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The updating of an Access Road full
view
We will create now a second full
view, for Linux Ubuntu objects, just 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 open 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, with 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.
Unfortunately, this is not always
possible if the number of links is too great. 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 in the view. 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. Then, to clear the diagram, you may remove
some objects in the view, or you may enlarge the layout adding a
new object to the view: Click in the explorer the view node
'tubun:: any', click into the beamer the 'Select' button of
the property 'Elements', and select in the explorer a new object
for this view.
The new node 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 other additions.
The good new is you use now a layout of 49 locations for the
nodes. The diagram nodes would be well positioned, to get a clear
network of links. Nonetheless, we have to be realistic. 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, and for instance, to split
the view in two complementary views.
Note: 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).
Note: the first view diagram and
'See why' text locations have been already saved. It does not
matter to not have them open during this second saving.
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 properties
which may modify 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 an implied GroupID.
We will use the view
'sqyl:: jerry' to test the application of the MySQL 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.
The
idea is to delete the matched global ACL 'jerry >> MySQL
server', and to see how the rights change in the view.
Close the diagram of the second
view 'tubun:: any'. Click 'Yes' in the dialog window, to close
this view. 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 explorer
the sqyl node 'MySQL server', then in the beamer, click the
tab 'ACL'. Into the sorted list of ACL, select
the ACL '<U>:: jerry:: >> MySQL server:: || grant ||
localhost'. Click the list button 'Delete'.
When the view has very complex paths, the updating of the access
paths needs several seconds. The user may see a message 'Please
wait' at the top left coin of the diagram. But this should not be
the case there.
The view 'sqyl:: jerry' is updated, both its diagram and its 'See
why' text. The resulting text is totally changed. The rights
of 'jerry' on 'BASE One' is now CREATE. 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 addon. This is why
deleting the global ACL 'jerry@localhost'
has produced a deleting of the second ACL 'jerry@localhost' on
'BASE One'.
As
we have already seen, the reading of a diagram is very intuitive.
An important property is to offer a 'smart' reading to the eye.
So, the rights is get now through this 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 properties, 'Elements', click the 'Select'
button, then click in the explorer the GroupID
'jerry§@local%'. The view
is updated. Move the new node to get this resulting diagram.
The first look shows no link between 'jerry' and 'BASE One'. This
is due to the indirect path 'the eye' may find via
'jerry§@local%'.
With or without this group
into the view, the overall result is exactly the same. The
presentation is different to remain intuitive.
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 wildcard 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'.
If you know how MySQL Server works, you may note 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.
If the MySQL Server ACS addon
finds for this view a direct path from 'jerry' to 'BASE One' that
forbids the current indirect path via 'jerry§@local%', then this
direct path would be drawn in a double-lenght-line
arrow, to indicate it is the only applicable one. To see it, we
may simply return to the next 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. This image of
the new diagram demonstrates the behavior of a full view.
Save your current work through
the command File → Save All (Ctrl+s).
Of course, to design access
controls for the MySQL Server, we cannot 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 us.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
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 last 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:
a set of 3 separate database
administrative roles to attribute to the IT technical staff, the
good rights for the good task, at the global and base levels;
a set of 10 separate technical
roles to attribute to the 10 sets of applicative transactions
that have to access to the bases of the MySQL Server;
from a structure of MySQL bases
designed to well match to this set of MySQL technical roles, the
access controls are efficient, easy to design, to configure and
to maintain.
For simple and stable
needs of access controls, MySQL
Workbench is quite good. It is also
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:
it cannot tell if a right
statement for 'jerry@local%' overrides or not a right statement
for 'jerry@%'; this means it does not allow to design a
differential naming space into the right statements, as we will
see Access Road help to do;
it cannot handle the rights at the
levels under the bases, like on a table, a stored procedure, a
view or a column; this means, for instance, it is not possible
to design a stored procedure, running under a specific secure
account, to provide a common high-security-level code to all the
applications accessing the MySQL Server.
Furthermore, MySQL Workbench cannot
use flexible strategies of access control, while Access Road is
able to design them.
There are some things to
remember first, about what you can and cannot do with the MySQL
Server:
You
cannot explicitly specify that a given user should be
denied access. That is, you cannot explicitly match a user and
then refuse the connection. This means it is not possible for
Access Road to match on an enabled conditional ACL without
rights. However, it is possible to set a flexible strategy to
attribute a 'small' unused right, like TRIGGER, to a small range
of accounts, defined in Access Road as an accounts-for-hosts
group, so that this range will be connected to the server, but
in practice without workable rights.
On the other hand, you can enable
access in the MySQL Server to all hosts on your network, except
one given host. The
wildcard characters “%” and “_” can be used in the hosts
group names. This is the way to enable access to all hosts. This
tutorial does not covered this feature, while Access Road is
able to do it.
There
are also some MySQL best practices to know:
The rights
statements that are assigned on a global basis are applied no
matter what the default database is. For example, with a global
DELETE right on the root 'MySQL Server', you can delete rows
from any table in any database on the server! It is wise to
grant global rights only to people who need them, such as
database administrators. For other users, you should use rights
statement at more specific levels only, for particular
databases, tables, columns or routines.
To keep rights for
temporary and nontemporary tables separate, a common workaround
for this situation is to create a database dedicated to the use
of temporary tables. Then for that database, a user can be
granted the CREATE TEMPORARY TABLE right, along with any other
rights required for temporary table operations done by that
user.
When you modify the
account's rights, it is a good idea to verify that the changes
set up rights the way you want. To check the rights for a given
account, use the SHOW GRANT statement. For example, to determine
the rights that are granted to an account with user name and
host name values of bob
and pc84.example.com,
use this statement: SHOW GRANTS FOR
'bob'@'pc84.example.com'.
With this last MySQL
best practicee, a SHOW GRANTS statement cannot show all the
applicable rights of 'bob', since for instance the
'bob@%.exemple.com' right statements are not listed. On the
contrary, the Access Road beamer displays all the ACL of 'bob' in
one list, and more, it is a sorted list.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Designing MySQL Server access
controls
with Access Road
First
strategy: administrative
and technical roles
This
access control strategy is simply derived from
the MySQL
Workbench ability to handle administrative and technical roles.
We
use the first access control form through proxies, seen in the
section 'Introducing the MySQL AclEntry'.
In
the explorer, click the UserID 'lp'. In the beamer, this
UserID has no 'ACL' tab, because it is a special type of UserID
called a Proxy, having no ACL. Click the tab 'Alias'. The
property 'Proxied account' shows that 'lp' has the account
'jerry' has alias reference. This means simply that 'jerry'
transfers all its rights on the MySQL Server to the Proxy 'lp'.
To
see it in Access Road, let's add
'lp' to the view 'sqyl:: jerry',
by the way of the known procedure. After a node moving, this
diagram is get.

The link from 'lp' to 'jerry' has a
comment at right, because it is always drawn near the source of
the link. The 'See why' text for this link gives the description:
'Is alias (<modify owner>) --
All Rights: PROXY'.
In this line of text, '<modify
owner>' is a generic mark to indicate this link implies a
change of the active UserID, there from 'lp' to 'jerry'. The
MySQL right PROXY is dedicated to this type of aliasing, and this
is why it cannot be selected in an ACL for MySQL Server.
Note: This is an example where an
alias relation is not modeled as a true generic alias, with the
generic Access Road properties, but as an ACS addon relation
which uses the generic vocabulary of the 'See why' text ('is
alias' and '<modify owner>') to describe the relation.
To
create administrative and technical roles, the
principle is exactly the same: the roles are proxied accounts
like 'jerry', and the easy administrative task is to tie the
proxies like 'lp' to a role, when the proxy is created. Into the
beamer, the account 'jerry' has a MySQL property 'Proxy
accounts', in the tab 'Members'.
Second strategy: differential
naming space into the right statements
This access control strategy we
will test is based on the rights sorting of the host names. For
instance, I may have:
an user desktop with a DNS name
'pc84.example.com';
in a space of 100 desktops named
from 'pc1' to 'pc100';
the MySQL Server host is put at
'sql.hosts.com';
there are application servers at
addressessss from 'ap1.hosts.com' to 'ap5.hosts.com', and from
'ap6.main.hosts.com' to 'ap8.main.hosts.com'.
Such
a name space has to be modeled by Access Road as an information
system. The IS root is 'com' with a child 'example' having the
100 'pc' ACS as children. This means the IS name sets the
components in a reverse order. Creating such an information
system is not necessary there, but it is explained in the first
tutorial.
We create the Access Road
accounts-for-hosts groups named 'com.example.%', 'com.hosts.%'
and 'com.hosts.main.%'. Access Road fills up automatically the
group 'com.hosts.main.%' with the application server hosts
'com.hosts.main.ap6', 'com.hosts.main.ap7' and
'com.hosts.main.ap8'.
The rights sorting of MySQL Server
selects 'com.hosts.main.%' before 'com.hosts.%'. We have already
modeled a group 'jerry§@local%'. To see an example of such
rights sorting through the ACL sorting, let's create a new
accounts-for-hosts group called 'jerry§@localho%', then an
INSERT-right ACL on 'BASE One':
In the explorer, click the
node of the ACS 'sqyl'. In the beamer, click the tab 'Rights
Users', and click the 'New' button of the property 'Own
Eligible Parties'. Select 'GroupID' in the dialog window, then
'OK'. In the creation dialog window, enter the name
'jerry§@localho%', select the type
'pattern-name_accounts-for-hosts group' and 'no' about the
administrative role, then click 'OK' to create the group.
In the explorer,
click the node of the Resource 'BASE One'. In the beamer,
click the tab 'ACL', and click the 'New' button of the
property list 'Sorted list for users'. In the creation dialog
window, select 'sqyl' as ACL manager, 'jerry§@localho%'
as Right User, 'INSERT' as single right, no condition group, and
click 'OK'.
Access Road has set
'jerry' as member of the new group. The beamer displays the new
ACL. Click the beamer back button, to return to the ACL
tab of 'BASE One'. The ACL list appears like this, with a
selection on the new ACL:

The open view 'sqyl::
jerry' is not updated, since the first applicable ACL for 'jerry'
has not changed. To do it, we have to delete the relevant ACL, on
the root 'MySQL server':
In the explorer,
click the Resource root 'MySQL server'. In the beamer, click
the first ACL '<U>:: jerry:: >> MySQL server:: ||
grant || localhost', then click the 'Delete' button. Confirm
the operation.
The view 'sqyl:: jerry'
is updated, and we see the right INSERT from the new ACL into the
link from 'jerry' to 'BASE One'. The 'See why' text of this link
confirms us the selection of the new group in the 'Current User:
(jerry, jerry§@localho%)'.
To use a differential name space in the MySQL Server rights, the
principle is to have the same set of MySQL accounts as users from
all the application servers, both from 'com.hosts.%'
and 'com.hosts.main.%'. This is an useful
simplification. Since the 'com.hosts.main.%'
rights are applied when the account is from these 3 hosts, this
is a mean to deliver restricted rights to these hosts. For the
other 'ap1.hosts.com' to 'ap5.hosts.com' hosts, it is possible to
deliver larger rights through the group 'com.hosts.%'.
Third strategy:
powerful dedicated accounts for secure routines
This
access control strategy is based on the DEFINER mode of MySQL
Server. We add an EXECUTE right on the new 'jerry§@localho%'
ACL: click
on the ACL in the explorer. In the beamer, click the tab
'ACL', then on the button 'Select' of the property 'List of
rights'. In the selection list, select only 'EXECUTE', then click
'OK'.
This new EXECUTE right
allows 'jerry' to execute 'procedure_one', as the 'See why' text
shows. Running under the account 'tom', the launch of the
'procedure_one' gives to 'jerry' a new access path through the
account 'tom', connected there under (tom, localhost).
This means it is easy to
set the 'tom' rights so that it delivers higher rights to
'jerry', but only under the control of 'procedure_one'.
It is possible to design a stored
procedure, running under a specific secure account, to provide a
common high-security-level code to all the applications accessing
the MySQL Server. This is an usual strategy to protect the most
critical applications.
Exit Access Road
But the time is over for
this large tutorial!
If you have trouble with
the behavior of Access Road, do not hesitate to read this
tutorial one more time. Remember
that, as a processing, the core of the MySQL Server simulation is
the management of the ACL sorting, the ACL inheritance and the
pattern-name containers. However, MySQL Server is just an
example. The MySQL ACS addon represents less than 10 % of the
total Access Road 0.7 code. Most of the subjects this tutorial
discusses are truly generic, for all the simulations.
With the full
views, Access Road offers an unique tool for studying and
improving the design of access controls. It is based on
extended capabilities to display efficient images and texts, full
of levels, significance and knowledge, so that the true power
remains in the human mind.
Save your current work through
the command File → Save All (Ctrl+s).
The purpose of the next
tutorial is to show how a NoMore-NoLess view may help to verify
an access control policy. The third tutorial will also explain
how the rights for a pair (right user, access target) may be
negative, and how to import and export data. After the examples
of Linux Ubuntu and MySQL Server, this third tutorial will take
the example of a Role-Based-Access-Control application.
How
to exit Access Road and save the current configuration is
described at the end of this
tutorial.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|