Access
Road 0.7.1 Learning access controls
|
|
Creating
ACS | Explorer | IS
Structure | Beamer
Editing
a list | Sketcher | Umask
This
getting-started one-hour tutorial is for learning the basic
commands of Access Road. It takes the example of a simulated
Linux Ubuntu®
software to show the handling of the umask feature.
This first tutorial
should be ridden by each Access Road user. 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. The approach is to
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 a Linux Ubuntu
operating system,
using
the explorer for showing the structure of the ACS,
using
the IS structure to display the inter-ACS relations,
using
the beamer for reading and editing the properties,
using
the sketcher to see the simplest and direct rights around an
object,
using
all these tools to understand the principle of umask in Linux
Ubuntu, as an example of the new learning capacity with Access
Road.
At any time, you may
choose to 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
an Access Control System
Run the Access Road
program from the installation instructions. Close the central
information box. Close each open ACS, if any, through the command
File → Close (the ACS node should be selected in the explorer
to close it).
You should have the main
Access Road window, without any internal window. Some window
border colors and title policies may change when you run it on
varied operating systems, but most of the user interface is the
same.
The main menu is very
simple. The active fields to operate with are generally included
in the varied internal windows. To create the out-of-the-box
simulation of a Linux®
Ubuntu®,
select in the main menu the command File → New → 'New
Access Control system'. This dialog opens:
Enter the name 'IO'
for the ACS IS, the name 'tubun' for the new ACS, select the
second choice 'Linux Ubuntu 8.04', and click 'OK'.
This question appears
(see the following image). Click 'Yes' then 'OK' to
create the IS physical node which will be the parent of the Linux
Ubuntu in its information system 'IO'. This dialog 'NEW
COMPONENT' appears. Enter the name 'one', click 'physical'
to create a physical node, then on 'OK'.
The question 'Do you
want to create another component' appears. Click 'No' then
'OK'.
Note: if you answer
'Yes', it is possible to create one or several physical or
logical IS nodes under 'one' and above the ACS 'tubun' node.
That's all to create the
ACS 'tubun'! Access Road makes the job. You should see the
opening of two internal windows: the explorer at the top left,
and the beamer at the top right.
The explorer is shown
there after a click to see the children of the node 'tubun'.
Generally speaking, and
about the three main explorer nodes, any simulated software in
Access Road is modeled as Access Control System(s). All the
searches about the access paths between the objects are done into
Access Road views, which are studied mainly in the next
tutorials. Generic rights are an universal description of the
rights, in a catalog any ACS may use.
|
About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The explorer
The explorer displays the structure of all the open objects in
Access Road. It is
always visible. The user may open and close the ACS and the views
after a selection in the explorer. In the main menu, several
commands listen what is the selected node in the explorer, to
detect on what object, like an ACS or a view to save, the command
has to be executed. To save, close or open
the ACS 'tubun', the user uses
in the main menu one of these 3 commands: File → Save,
File → Close or File
→ Open → Open Access Control System.
The explorer displays
the main components of 'tubun', that are the resources like a
directory, the userIDs like a personal account 'tom', the
groupIDs like the group 'tom', the AclEntries and the proper ACS
rights of 'tubun'. For an ACS, the explorer may displays varied
lists of components. Of course, the nature of the ACS components
depends on the nature of the ACS, and thus, the nature of the
simulated software, like Linux®
Ubuntu®
there.
The explorer comments
each first-level node under an ACS as an access
target or a right
user. A right user
is simply an entity which has the capacity to access to an access
target, if the ACS allows it. The main type of right user is
EligibleParty,
which has several subtypes in Access Road. The most common type
of access target is Resource,
which has also several subtypes.
An executable program into an operating system is an example of
right user being also an access target. Such an entity is modeled
as an Actor
into Access Road. This generic
vocabulary is used for all the ACS (See the glossary
to go further).
The explorer displays also the AclEntries of the ACS 'tubun'. For
the moment, there is no AclEntry. Finally, the explorer shows the
'types of ACS right'. They are the specific rights into a Linux
Ubuntu. Some are used for accessing the file system, like 'r' to
read a file, and some are reserved by the ACS addon to a subACS,
like 'authorize'.
To keep an eye on the ACS components, it is possible to open a
dedicated window for one open ACS. Select the ACS in the
explorer, then use the command Window → View diagram or
ACS tree. The tree of the ACS components is displayed exactly
like into the explorer. However, the tree nodes are not
selectable.
The subACS
To explore the 'tubun'
default components, click the node 'Resources (access
target)' to open it, then open the first child node 'files_tree'.
The first level of file directories appears. An ACS like Linux
Ubuntu has two Resources subACS named 'authorization' and
'capability'. A subACS is a subset of components and rights
having a specific logic. This is added to the main set of
components in the ACS, like the file system and the general
userIDs in a Linux Ubuntu. You should see the Ubuntu tutorial for
studying these subACS, but it is not necessary in this
getting-started tutorial.
The
point here is a subACS may have a specific subtree of resources,
like 'authorization' there, and/or a specific set of GroupIDs.
Click the node 'GroupID (right user)' to open it. The
explorer shows the first two children 'authorization_subacs' and
'capability_subacs', which are two separated sets of groups in
Linux Ubuntu. As you see, the subACS 'capability' has a set of
GroupIDs, but no set of resources.
|
About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The IS Structure
An
ACS belongs to an Information System. The 'IS structure' is the
internal window to display the tree of all the information
systems, with theirs children nodes. Select in the main
menu the command Window → IS Structure (or Ctrl+i). The
'IS Structure' window appears. It has two parts: at the top, four
properties are displayed, and a tree of nodes is set in a second
part. The last node in the tree is for the information system
'IO' we have just created for the ACS 'tubun'. Click
the node 'IO', then on its children 'one' and 'tubun' to open
them. The result is this
following window, where the ACS 'tubun' and its two subACS are
visible.

At the opening, the 'IS structure' window shows the properties of
the first child under the root, and it is there 'IPv6'. The
property 'Type' tells it is an information system, like every
direct child of the root. The property 'Open' tells it is closed,
and this mean this IS has no open ACS at the moment.
The IS 'IPv6' and 'IPv4' are default IS Access Road creates to be
reserved to the modeling of the two IP address spaces. If you
define an ACS name by its IPv4 address, like '192.168.50.4', it
is mandatory to put the ACS in the IPv4 information system. In
such a case, '192' has to be the first child of the node 'Ipv4',
'168' is a child of '192' and so on, since the IP address space
has a tree structure.
Click 'IS
Structure', the root node of the tree. A
list named 'ACS Addons' is displayed at the top of the window.
The list contains two items: 'Editor: Accbee - AcsAddon: MySQL '
and 'Editor: Accbee - AcsAddon: Ubuntu'. They are the ACS addons
Access Road has detected during its opening procedure, among the
executable files under its working directory. The creation of a
Linux Ubuntu ACS is proposed in the ACS creation dialog, because
Access Road had registered the relevant ACS addon.
Click 'tubun', the
node under 'one'. The
properties of the node 'tubun' are displayed in three tabs named
'Basic', 'General' and 'Links'. The property 'Tied child' is set
at 'false'. This means this ACS is not opened at each opening of
its parent. This property is set at 'true' for instance to
enforce the opening of an application its operating system
launches at its proper starting. The two resources subACS of
'tubun' are visible under its node. On the other hand, the
GroupIDs subACS of an ACS is never displayed by the IS structure.
Clicking all the path nodes, from the tree node 'IO' to the
tree node 'authorization', changes the tab 'Basic' at the top of
the window. This action shows that every node is open, while the
types change from the value 'information system' to 'subACS'.
Generally speaking, creating or opening an ACS in Access Road
opens all its parent nodes in its information system. An
information system node is closed when it has no open ACS as
direct or indirect child. When an IS structure node is closed,
its icon is changing. For an ACS having a proper icon, like Linux
Ubuntu, closing the ACS changes the icon to the default one, and
opening the ACS restores the proper icon.
Access
Road is designed to handle easily thousands of closed ACS, and
hundreds of open ACS. The
IS structure gives an overview on the static relations between
all the ACS, even if they are closed. The
IS structure window closing, like any internal window, is get by
clicking the cross, at the top of the window.
Most of the windows may also be iconified or enlarged by the
user. The location and the size of a window may be changed with
the mouse.
|
|
The beamer
The beamer should be
always visible, but it may be iconified by the user. It displays
the structure and the
properties of a selected open object in the explorer: an
ACS, any ACS object, view, generic right. The beamer always shows
the current values in the Access Road base. The beamer is the
unique window to see and edit the properties of an object.
The property changes in the beamer are propagated to the other
windows, and also to the other properties in the beamer.
The
only exception about the objects editing is for the global
handling of ACS and views, that is to create, close, open them in
the database, save and import them to/from files, and remove them
from the IS structure. This is reserved to the Access Road main
menu, where all the command names are clear. However, adding or
removing a component to an ACS or a view is also the
responsibility of the beamer. Like the explorer, the beamer
displays only the relevant properties of each object, and the
beamer allows to navigate among the open objects.
To
explore the 'tubun' default components, click
in the explorer on the node 'tubun', if it is not already
done (it is selected if you have followed strictly this
tutorial). Because the explorer is selecting the node 'tubun',
the beamer displays all the properties of this ACS in a set of 13
tabs. Linux Ubuntu is simulated in an ACS addon. This addon
defines the main structure and the behavior to the ACS 'tubun'.
ACS is indeed the most complex object Access Road models. This is
why the number of properties is quite large. The good news is the
Access Road user has generally not to understand all these
properties. They explain the Linux Ubuntu behavior when one wants
to see the details. But they are not necessary to design the
Ubuntu rights. After all, Access Road simulates Linux Ubuntu for
you...
All
the Access Road names are made of components with the pattern '::
' as separator. This is also true for simulating a Linux Ubuntu,
for which the internal separator in a file name is '/'. In
the visible tab 'General' of the beamer, let's see some first
properties of the ACS 'tubun':
the
ACS name has a special structure which is derived from the
location of the ACS in its information system: 'IO' is the name
of the IS, and 'one' is the name of the physical node which is
the parent of 'tubun' (you may see 'one' as a computer),
you
may enter any comment in the Comment white field: click
it, enter your text, then press Enter to edit the value.
A whitespace is added at
the end of your text, when the new value is registered into the
Access Road base (but not saved). Generally speaking, the beamer
displays exactly the internal state of the base, at any time.
the
ACS type tells it is a Linux Ubuntu simulation, and it is also
visible through the name 'Ubuntu' of the ACS addon. (New in
0.7.1) The policy checksum of the ACS depends on the ACS
structure, the subACS, the types policy and the rights policy.
All these properties are set at the creation of the ACS, and
they are immutable. The policy checksum helps to detect an ACS
that is derived from another one. If the new ACS properties have
been changed for some of these key properties, the checksum
allows to see it, while there is no change of the ACS type.
When a field is in white
into the beamer, it may be edited directly by the user. When the
field is in yellow, the editing is forbidden by Access Road. The
last two properties show clearly the limits of the ACS addon
Ubuntu. The property 'Incomplete behavior' is true, because the
POSIX ACL are not simulated, among other things. Of course, even
if the property is set 'false' for another ACS, this choice is
done by design, and it does not take account of the Access Road
bugs. The property 'Incomplete objects list' is also true,
because the complete Ubuntu file system, including all its
components, is not created into 'tubun'. This ACS addon creates
the first level of file directories, and it is up to the user to
complete them.
In the explorer
click the directory 'home', under the node '<files_tree>',
to explore the 'tubun' default components. In the tab 'General',
the name of this directory shows it is simply derived from its
location in its ACS. For
the object 'home', 'General' contains 5 first standard
properties: name of the object, its IS, its ACS, its comment and
its type. Some
property are displayed with one or several buttons, like 'ACS'
with a 'See' button.
Click
the 'See' button of the 'ACS' property. The
explorer selects the 'tubun' node, and the beamer switches to
display the properties of 'tubun'. Through the 'See' buttons, the
beamer allows to navigate
among the objects of the base. It
displays here the same tab 'General' because it exists both for
'home' and 'tubun'. If 'home' is in the beamer with for instance
the tab 'As Directory', and if another directory is selected for
the beamer, the same tab 'As Directory' will be shown into the
beamer for the new selected object, to facilitate the comparison
between objects.
Click
the beamer back button:
it is the yellow/grey arrow on the top left of the beamer, just
under the beamer title. The beamer returns to the previous
object, that is 'home'. In the 'General' tab, the fifth value
'Access Target Type' may be updated by the user, which may choose
in a list of proposed values. Let's try to change the 'home'
type.
Click
the little black triangle, at right of the 'Access Target
Type' property. A list
appears. Click one of 3 proposed values. Access
Road displays the error message: 'home has a type which forbids a
type editing.'. This illustrates how the beamer is designed. It
displays the properties in a standardized way, like there the
types in the selection list, but this does not mean all the
values are possible. There are several
levels of selection and control, for the new value of a property:
First,
from the 'home' ACS policy ('tubun' there) or from a
preprocessing depending on the object type, Access Road defines
a first list of the allowed values, for the user choice, and
this list is displayed by the beamer,
Second,
after the user choice, the selection is send to the Access Road
base which checks the new value from the ACS integrity rules.
Here, the current type '<byAcsCreator>' of 'home' means
that this object has been created at the creation of the ACS,
and its type cannot be changed by the user. The aim of this
integrity rule is to never alter the files system, since any
Linux Ubuntu does have a 'home' directory.
All the efforts have
been done to define powerful generic integrity rules, covering
all the Access Road objects, and to complete them with specific
integrity rules for a given ACS. These integrity rules are very
versatile and powerful. The aim is to limit the risk of error in
a simulation, due to a user command or a program command from
outside the Access Road base. The ACS integrity rules about the
object types will be seen at the end of this tutorial.
|
|
Editing a list
We
will see now the handling of buttons and lists in the beamer. For
the user, the beamer is
the only way to
create some objects in the ACS and the views.
It is also useful to
link some objects together. Click
the 'As Directory' tab into the beamer window. This
image shows the state of the beamer:

The tab 'As Directory'
appears in the beamer only for a directory, like 'home' there.
The type of 'home' is also put into the title of the beamer. The
property 'Children' is associated to a list and 3 buttons. The
list displays the current children with their Access Road full
names. The full name of an ACS object starts with the ACS name.
Each directory child is a Resource. For a resource,
the name contains the path of all the indirect parents.
The list is in yellow to
tell it cannot be directly changed, while the buttons play this
role. There are listed hereafter:
'See'
lets the user to select in the explorer the current selected
value in the beamer list, and this means of course that 'home'
would be no more displayed.
'New'
allows to create a new object and to add it in the list, by the
way of an updating of the base. The type of the object to create
is of course derived from the current property the beamer
displays: 'Children' there.
'Delete'
is the inverse operation, to delete one or several selected
items in the list, by the way of an updating of the base.
The 'New' button always
creates the object with the right type. In the context of this
property, the ACS 'tubun' manages varied children. For helping
the user to avoid a wrong creation, clicking the button 'New'
selects the allowed types into the relevant ACS. This is always
true, whatever the displayed object and the property in the
beamer, like 'home'/'Children' here. However, like the 'Access
Target Type' property above, a selected type for a creation may
still be rejected by the base at the second step.
Click 'New'. A
dialog box appears at the center of the Access Road window, to
enter the main properties of a new 'home' child. The ACS
configuration of 'tubun' specifies that it handles 4 types of
resources.

'Resource' is the basic
type. 'Directory' is a Resource having children. 'Actor' is a
Resource being a right user. These 3 types are generic, and they
are defined in the glossary.
'Executable' is specific to the ACS addon Linux Ubuntu, as a type
of Actor having complementary properties.
Like
the
'Access Target Type' property, the Access Road base checks the
new child from the ACS integrity rules. If you try to create a
new Actor under 'home', whatever the properties the user enters,
the ACS will return an error message 'Through
the ACS constraint 'Directory.TypesOfChildFor', the parent
accepts only children having the types <byAcsCreator>,
<byAcsCreator> authorization, directory'.
Indeed, since the Actor creation dialog does not propose these 3
types, this means it is not possible to create an Actor under the
directory 'home'. For another type of directory, the selection of
types may be different. In all cases, Access Road informs the
user about the reason of a refusal.
Select the case
'Directory' then click 'OK'. The following dialog box
'Create a new Directory' appears.

Enter the name 'one', do not enter any 'Account', select
'directory' as the 'Access Target Type', then click 'OK'.
It is possible to enter these properties without the mouse, from
the computer keyboard using the keys 'Tab' (or '→'), '↓',
'↑', and 'Enter'.
The new directory
'one' is created in the base. The list of the 'home' children
is updated both in the explorer and the beamer. The 'Children'
list is resized in the beamer, to take account of this new item.
The default value '<immutable> directory' has been proposed
for the Access Target type, in the creation dialog. There is a
standardized way to 'freeze' the state of an ACS object. Access
Road uses the pattern '<immutable>' in the type to forbid
most of the updatings for this ACS object. This allows to
protect it from the user errors, like the deleting. At any
moment, the user may reset the type to '<immutable>', like
from 'directory' to '<immutable> directory' or the inverse
action. The base imposes strong constraints on the type changes,
whatever the proposed values in the beamer. It is always
forbidden to switch from the type 'directory' to 'executable' or
'<immutable> executable', for instance. Thus, the basic
type of an ACS object remains unchanged after its creation.
Again, remember there is a second pattern to forbid the deletion
of an ACS object, and it is based on '<byAcsCreator>'. Such
an ACS object type cannot be changed by the user. He has no
ability to delete the object, as for the 'home' directory.
To delete the 'one'
directory, the 'Delete' button may be used in the list, if 'one'
is selected among the children of 'home'. The second way is:
Select 'one' in the list, then click 'See'. The beamer
displays the directory 'one'. Click the top right button
'Delete it' in the beamer, and confirm the deletion. The
directory 'one' is then deleted in the base, the explorer and the
beamer. The beamer title becomes 'Beamer on a closed element',
until the next selection of a node in the explorer.
Caution: deleting a
Directory in a Resources tree deletes all its direct and indirect
children. This is true into an operating system like Linux
Ubuntu. Indeed, for Access Road and by default, this is true for
all the directories whatever the ACS.
Click the node
'e_jerry' in the explorer, under the node home:: jerry:: d_jerry.
In the beamer, click the tab 'AG'. The
beamer has the following state:

The tab 'AG' means Account/Group. The title tells us 'e_jerry' is
an Executable, that is a special type of Actor in Linux Ubuntu,
dedicated to the simulation of a program. We have not ridden the
Linux Ubuntu ACS addon documentation, but the beamer shows us
many things about the nature of 'e_jerry', as followings:
'e_jerry'
is a Resource, since the first three tabs are common to all the
Ubuntu Resources, like with the directory 'home' for instance,
'e_jerry'
is a special Resource having AclEntries, since there is the tab
'ACL', while the directory 'home' has no such property,
'e_jerry'
is a special Resource, called an Actor, since there is the tab
'As Actor',
'e_jerry'
is a special Actor, called an Executable with a dedicated tab.
The
beamer follows the hierarchical suite of concepts which define
the object, and it may add some special tabs like for the
AclEntries. This
means simply that the Executable tab is after the Actor tab
because an Executable is a type of Actor. For the directory
'home', the Directory tab is after the three first Resource tabs
because a Directory is a type of Resource. After a little
practice of Access Road, the beamer becomes the easiest way to
remember the nature of a selected object in any ACS.
The
user may have an Access Road comment
on each property, when
the mouse arrow is near the property name. For instance, the
message 'The main group which contains this resource'
is the tip of the property 'main Group' in the beamer. Most of
the properties of this 'AG' tab are generic, for all of the ACS
managing Accounts and/or Groups. However, the beamer receives
also the description of some specific properties from the Linux
Ubuntu ACS addon. This is how the property 'other as NX rights'
appears only for a Linux Ubuntu ACS.
|
About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
|
The purpose of this
tutorial is not to master the simulation of Linux Ubuntu. Let's
say here that a Linux Resource may have an account and a main
group. They are the two first properties the AG tab displays. We
see the account 'jerry' and the group 'jerry'. Access Road adds
the patterns '<U>' for UserID and '<G>' for GroupID
before the last component of, respectively, any UserID name and
any GroupID name. This is true for all the ACS. In the case of
Linux Ubuntu, an account and a group may have the same last
component in the names, like 'jerry' there.
This AG tab handles
varied buttons we have to understand. The properties are
associated to new buttons, as followings:
'See'
has already been seen in this tutorial,
'Select'
allows, for a single value or a list, to update a value in the
base, through its selection in the explorer or in a displayed
list; it is used instead of 'New' for selecting and not creating
an object, as for instance the account to select for the
executable 'e_jerry',
'Clear'
sets a single value to null,
'Remove'
replaces, into a beamer list, the 'Delete' button for removing
in the list without deleting in the base; the link between the
two objects is deleted, but the removed object remains visible
in the explorer,
'Prev.'
means 'previous' in a list, to copy the values of the upper list
in the beamer tab into the current list; for instance, click
it for 'main Group rights' would set the rights to 'ctrl' only,
by copying from the previous property 'Account rights' into the
same tab.
With the button 'Select'
of the Account property, it is possible to select an UserID in
the explorer. Click the Account 'Select' button: the
following little dialog appears to indicate the type of the
selection to do, that is 'UserID' here. To NOT change the
'e_jerry' account, click the button 'Cancel' of this
dialog.

The behavior of Access
Road may be different. With the button 'Select' of the 'Account
rights' property, the explorer is not implied since a list of
rights appears for the selection. Click the Account rights
'Select' button. The following window appears:

Access Road displays the
rights without redundancy in the current list. There are two
cases. If you select the right '|mdown|', it is added to the
'e_jerry' list. If you select another right, it would not appear
into the beamer list. This is because the current right 'ctrl'
includes the three rights 'w', 'x' and 'r', from the ACS Linux
Ubuntu point of view. If you have added '|mdown|', select the
right '|mdown|' in the Account right list, and click the
'Remove' button to return to the initial state where 'ctrl'
is the single account right. Otherwise, close the 'Selection'
window for the rights. On the other hand, the property 'main
Group rights' displays the two rights 'r' and 'x' because they
are independent.
An ACS may deliver
complementary data about its properties. Click the node
'tubun' in the explorer, and click the tab 'See Why' in the
beamer. This map uses as
keys, in the list at left, the property names the beamer displays
for this ACS. Click the key 'All the rights'. The
value at right is a short text describing the logic of the Linux
Ubuntu rights.
Creating an ACS
object
The creation of a new
Resource may be done from its parent, as we have seen there for
'one', but also from its ACS, from the tab 'Access Targets' and
the property 'Own Resources'. In the beamer, the ACS tabs allow
to perform the following operations:
into the tab 'Right Users',
creating an EligibleParty (UserID, GroupID, Actor,...)
from the property 'Own Eligible Parties', and creating a
Right-User VirtualFolder from the property 'Right-User
VFolders',
into
the tab 'Access Targets', creating
a Resource (Resource,
Directory, Actor,...) from the property 'Own Resources', and
creating a VirtualFolder
of Resources from the
property 'VFolders of Resources',
into
the tab 'Rights 2', creating
a typed privilege from
the property 'Typed Privileges', and creating
a linked privilege from
the property 'Linked Privileges',
all
the other ACS properties in the beamer are only for reading a
property, not for editing.
An AclEntry is
always created from its Resource, at the tab 'ACL'. The Bridge
is created with the Actor which is the Bridge source. The Hard
Alias is created when its hard reference is created.
All the other relations
between two ACS objects are made through a selection of an object
into the explorer, without creation of a new object in the Access
Road base. For instance, the Account/Group rights are managed
mainly by the Resources, as internal properties.
To
summarize this section about the beamer, the behavior of Access
Road at each selection depends on the property and the ACS.
Access Road indicates what type in the explorer is expected, like
UserID there, or it displays the list of the new values the
property may have, like the Account rights here. The choice in
the explorer is checked by the base, and the new values list
comes from the ACS policy. Finally, you simply have to know that
Access Road works for you to authorize the allowed values, at any
property change.
|

About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary

|
The sketcher
Let's
take now the easiest part of this tutorial: the sketcher.
In the main menu, select the command Window → Sketcher.
Select in the explorer the Executable 'e_jerry'.
The sketcher window
appears at the bottom right of the Access Road window. You should
extend it to the right for having the following image:

The sketcher always
shows the current selection of the explorer (and the beamer) like
'e_jerry' there. At each selection, Access Road chooses the
objects to put around the selected object. The user cannot modify
the view in the sketcher. The drawings of the ACS objects depend
on their general types. These drawing patterns are common to all
the ACS in Access Road, and to all the views.
The sketcher contains
the following items:
the
central node is the current selection: 'e_jerry',
at
the top line, the main direct right users which have an access
on 'e_jerry'; there are its account 'jerry' in a smaller
drawing, and the groups 'jerry', 'users' and 'AllUserAccounts';
as you may see, executables (as 'e_jerry'), accounts (as
'jerry') and groups have each a specific drawing,
at
the bottom line, the main direct objects on which 'e_jerry' has
some rights: 1 account and 3 groups are displayed,
most
of the effective rights are shown near to the arrows or
lines between the nodes, and they are explained in the next
tutorial,
the
account 'jerry' has the right 'control' (ctrl) on 'e_jerry', and
'[own]' means this account owns this resource; this data is
simply the image of what the beamer displays in the relevant
property fields,
the
group 'users' has the rights 'view' (vw) and 'execute' (x) you
may consult under the explorer node 'types of ACS right', (click
a right to see it in the beamer, and read the property
'Generic Right')
the
executable 'e_jerry' has the link 'init contxt' on each of the 4
bottom objects, and this means 'initial context' to tell that
'e_jerry' is a program running under all these right users.
Access Road handles in
the views several links, like 'init contxt' there, which are not
simply the rights between two objects. The glossary
defines all the link types Access Road uses in any view. They
will be presented in the next tutorials. In a view, the only
active objects are the nodes, not the links or the rights.
Click the node of
the group 'users', to select it in the explorer. 'users'
becomes the central node into the sketcher. In this case, the
sketcher shows the members of 'users' since it is a group, and it
shows the executable 'e_jerry' as right user. 'e_jerry' is the
single target. To return to 'e_jerry' in the sketcher, let's use
the back button in the beamer.
In the sketcher title,
'no updating' means the sketcher view does not change if some
rights or other relations are changing in the Access Road base.
The sketcher is the simplest view in Access Road, and this is not
the behavior of the other views. If the object to display has too
numerous links, like an ACS or a right, or if there is no link at
all, like a view, the sketcher displays a grey rectangle. The
most complex rights are not processed in the sketcher, even if
they are direct. For instance, with a Linux Ubuntu file, the
'other' rights and the AG inherited rights are not displayed.
Use the key '↑' of
the keyboard to select in the explorer the group 'tty', then
'tom' and 'sys'. See the result in the sketcher.
In conclusion, the
sketcher is designed to simply jump from one object to another.
It shows the simplest direct links and rights. Try it on any
'tubun' object, and enjoy its simplicity!
With
the explorer, the IS structure, the beamer and the
sketcher, Access Road offers a powerful user interface. It
becomes more easy to define and understand varied simulations.
Let's
now apply our new skills for learning how Linux enforces the
account rights of a new Resource, from the account properties.
|

About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary

|
Understanding Linux umask
It
is recommended to save
the Access Road base,
for reusing easily this state in the next tutorial:
In
the main menu, select the command File → Save All (Ctrl+s)
Select in the
explorer the Executable 'e_jerry'. Click the 'Select' button
for the property 'Account', in the tab 'AG'. A selection
dialog box appears at the top of the main window. Select as
new Account, in the explorer, the UserID 'games' under the node
'UserIDs (right user)'.
The 'e_jerry' account is
updated normally, but also all the other properties in the 'AG'
tab. If it is still open, the sketcher does not change. The
sketcher may then be wrong, until the next normal selection
in the explorer! To close the sketcher, simply click the
top right cross of its window.
The property changes are
due to a requirement in the 'tubun' ACS, to simulate Linux
Ubuntu. Editing a Resource UserID produces the following changes:
the
selection of the new-UserID default group, for being the new
main group of the resource,
the
umask values of the new UserID are applies to the 3 AG rights of
the resource.
Note: This is an example of ACS behavior it is not possible to
specify through the ACS configuration the beamer displays. As it
is too complex, this is the responsibility of a specific Java
code in the ACS addon. To understand this ACS behavior, the user
should read the Linux documentation... or it may use Access Road
to see it in action.
Click
the 'See' button of the Account property. The
beamer shows the 'AG' tab for 'games'. The property 'UMask
for denying' has the value '--- --- ---'. This means that there
is no umask at all for 'games'. This is why the 3 'AG' rights of
'e_jerry' is now the right 'ctrl', the maximal one.
Select the UserID
'jerry' in the explorer. Its
umask is '--- -w- rwx'. At this step, if you are not familiar
with the Linux umask concept, you should tell: this is quite
difficult to understand! It is now the time to see the
power of a simulator helping you to learn Linux access controls,
as an example of the services Access Road provides for any
simulated software.

Let's
set the mouse arrow on the property 'UMask for denying', to read
this tip: 'The umask format is ''---- --- ---', where the allowed
ranges are from '---' to 'rwx' for Account, Group, and Other'. To
see it in practice, it is interesting to change the umask of,
say, the UserID 'jerry', then to reset the Executable 'e_jerry'
account to this UserID.
The
initial 'other as NX rights' of 'e_jerry', under the 'jerry'
account, was 'x' (see the image in 'Editing a list'), but this
was not due to the 'jerry' umask. We will use it now for
'e_jerry'.
Click
on the executable 'e_jerry' in the explorer. In the beamer,
click the 'Select' button for the property 'Account' in the
tab 'AG'. In the explorer, select the UserID 'jerry'.
The 'other as NX rights' of 'e_jerry', under the 'jerry'
account, become null.
For the account 'jerry', the
tab 'AG' and the property 'UMask for denying' , instead of '---
-w- rwx', replace the last value 'x' by '-' (do not forget to
enter 'return' to update the base).
Click
on the beamer back button to be once again on the executable
'e_jerry' and the tab 'AG'. Reset the 'e_jerry'
account to 'jerry' one more time.
This
resetting of 'jerry' enforces the reading of the new umask
value. The result is a right 'x' for the property 'other
as NX rights' of 'e_jerry'.
The
removing of 'x', at the end of the 'jerry' umask, has produced a
new 'x' 'other' right for 'e_jerry'. This is why the umask
name in Access Road is 'UMask for denying'. 'x' is
removing from the resulting new rights of a resource, if it is in
the account umask. Otherwise 'x' is put in the rights.
Note
1: in Access Road, the base is always consistent. Any property
change is propagated to all the relevant objects. The user has
never to command explicitly the updating of the linked
properties. If the previous procedure resets the same account
'jerry' to read its umask, it is not a design error in Access
Road. This is due to the specification of the umask. This
property is ridden by Linux Ubuntu only when the account is
changed or a resource is created. Access Road simulates this
behavior.
Note
2: The umask of the UserID 'jerry' does NOT explain the initial
values of the 'e_jerry' AG rights, at the creation of the ACS,
because the ACS addon provides an additional setting.
The
umask value is composed of 3 sections for driving the 3 Account,
Group and other rights. If you want to continue the test of
umask, change the 'r' and 'w' values in the umask for Account,
for instance, and repeat the previous procedure. Keep in mind
that, in Linux Ubuntu, 'ctrl' is the sum of the rights 'r', 'w'
and 'x' on a Resource.
One
should tell each access control concept is not very difficult to
understand. But unfortunately, these concepts are precise and
very varied from one software to another one. The next tutorial
will give a second example with MySQL Server®.
Access Road is truly unique to learn the access control concepts
well, and to remember them.
Exit
Access Road
We
hope you enjoy this first Access Road tutorial. The next one is
for designing access controls.
To exit Access Road:
In
the main menu, select the command File → Exit
A
dialog box requests if you choose to save all the open ACS, views
and GUI configuration.
Click
the 'No' button.
Then,
the changes about the umask are not saved.
The
main window is closing. At the next opening, the locations of the
open internal windows at the last saving will be restored, with
the same open ACS and open views.
|

About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
One-hour
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|