![]() ![]()
Access
Road 0.7
|
|
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:
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 on the 'OK' button. This question appears (see the following image). Click on '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 on 'physical' to create a physical node, then on 'OK'. ![]() ![]()
The question 'Do you want to create another component' appears. Click on '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, to comment 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. |
![]()
Two-hours tutorial for designing access controls One-hour tutorial for verifying access controls ![]()
|
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 on 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 on 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. |
![]()
Two-hours tutorial for designing access controls One-hour tutorial for verifying access controls ![]()
|
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 on 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 on '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 on '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 tis node. On the other hand, the GroupIDs subACS of an ACS is never displayed by the IS structure. Clicking on 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 tens of open ACS. The IS structure gives an overview on the static relations between all the ACS, even if they are not open. To close the IS structure window, like any internal window, click on the cross at the top right 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':
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. Click in the explorer on 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 on 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 on 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 on the little black triangle, at right of the 'Access Target Type' property. A list appears. Click on 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:
Generally speaking, 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 may be 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, this is the only way to create some objects in the ACS and the views. It is also useful to link some objects together. Click on 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:
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, the button 'New' proposes to the user 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 always be rejected by the base at the second step. Click on '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 on '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 on '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 any updating. This allows to protect the ACS object from user errors, like the deleting of the object. At any moment, the user may reset the type to '<immutable>', like from 'directory' to '<immutable> directory' or the inverse action. Furthermore, 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 on 'See'. The beamer displays the directory 'one'. Click on 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, this is always true, even if the ACS is a MySQL® server simulation, for instance. Click on the node 'e_jerry' in the explorer, under the node home:: jerry:: d_jerry. In the beamer, click on 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 that explains what is an Executable, but the beamer shows many things:
Displaying an object properties, the beamer follows the hierarchical suite of concepts which define the object. 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. However, this presentation has some restrictions, because there are some tab names which tell nothing on the type of the displayed object, like for instance 'General'. 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.
|
![]()
Two-hours tutorial for designing access controls One-hour tutorial for verifying access controls ![]()
|
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:
With the button 'Select' of the Account property, it is possible to select an UserID in the explorer. Click on 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 on 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 on 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 on 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 on the node 'tubun' in the explorer, and click on 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 on 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:
An AclEntry is always created from its Resource, at the tab 'ACL'. The Bridge is created with the Actor which is the Bridge target. The Hard Alias is created with its hard reference. 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. |
![]()
Two-hours tutorial for designing access controls One-hour tutorial for verifying access controls ![]()
|
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:
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 on 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, Let's now apply our new skills for learning how Linux enforces the account rights of a new Resource, from the account properties. |
![]()
Two-hours tutorial for designing access controls One-hour tutorial for verifying access controls ![]()
|
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 on 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 on 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:
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 on 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 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 on 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. |
![]()
Two-hours tutorial for designing access controls One-hour tutorial for verifying access controls ![]()
|
Creating ACS | Explorer | IS Structure | Beamer
Editing a list | Sketcher | Umask
®All trademarks are property of their respective holders. Copyright ACCBEE – 22 February 2012