.PL63 .PN1 .....L.....................................R...L.....................A .FO2 =AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>@@ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ UNOTE 094 Page # of 4 .HE5 .....L.....T..T.........................................R..L..................A From ‰:‰ Customer Services~ Ref: UNOTE 094~ Re‰ :‰ Examples on configuring Uniplex Windows~ 12 Jun 92~ ‰ ‰ through XDesktop rule files. =AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>@@ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ .....L..T.......T.......T.......T.......T.......T.......T.......T...J TASK~@@ EEEE This document gives examples on how to configure Uniplex Windows through the use of the XDesktop Rule files. METHOD~@@ EEEEEE References are made in this UNOTE to the Version 7.01 manual@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII "The Uniplex Windows Configuration Guide" herinafter referred@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII to as "UWCG".@@ IIIIIIIIIIIII Before one attempts to configure the Rule files, one should know where they are located in the file system and the system of precedence that determines which rules are used. First: if no rules are defined anywhere on the system at all XDesktop will default to hard-coded emergency rules. As "rules" these emergency rules are virtually non-existant: they will allow limited dragging of icons and the 'select' trigger action, which are hard-coded; but otherwise no amount of multiple-clicks on an icon will perform anything. Also, the icon's bitmap used in emergencies is the "?" bitmap which again is hard-coded.~ Assuming the System Rule File is in place (as defined by the X resource "XDesktop*SystemRuleFile" which is normally set to /usr/x/lib/sysinfodir/${LANG:=C}) these rules define all the default actions and appearances of the XDesktop. These rules can be overridden through the use of a User Rule File the name of which is defined by the X resource "XDesktop*UserRuleFile" (normally set to .xdtuserinfo): this rule file must be kept in the user's $HOME directory. Any rules defined in the User Rule File which conflict with rules defined in the System Rule File will take priority over the System Rule File: note however that the System Rule File will still be read. The User Rule File is used, as it's name suggests, to define rules for an individual user. These rules can be over­ ridden through the use of a Directory Rule File the name of which is defined by the X resource "XDesktop*DirectoryRuleFile" (normally either ".xdtdirinfo" or, more commonly in Uniplex Windows installations, ".xdtdir/C"). This rule file is held in the directory to which those rules must apply. Any rules defined in this rule file which conflict with the rules defined in the User Rule File will take priority over the User Rule File. Note that the User Rule File will still be read. The Directory Rule File, as it's name suggests, is used to define rules for the contents of an individual directory whether that directory is a subdirectory of a user's $HOME directory or whether that directory exists elsewhere. There can only ever be at most one System Rule File in effect per system, at most only one User Rule File in effect for each user and at most only one Directory rule file in effect for each directory. .PA Examples on restricting user access to certain area of the Unix filesystem. .....L..T.......T.......T.......T.......T.......T.......T.......T...J Example 1: How do I prevent access to dot files (eg .login) for@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII user "fred"?@@ IIIIIIIIIIII Because the rule needs to apply to only one user, in this case "fred", only "fred"'s User Rule File needs to be amended. If the dot files are not displayed in the directory windows then the user cannot access them by normal means. Thus the rule required is simply: icon_rules{ .* {title=;picture=} }@@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA An explanation of the individual components of this rule fol­ lows: icon_rules{~@@ AAAAAAAAAAAA A component of rule files that describe the behaviour and appearance of files when represented by icons. (page 6-30 UWCG). Can also be called "ic". .*~@@ AAA For all filenames that start with a "."... (See "Patterns" on@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII page 6-31 UWCG) {title=~@@ AAAAAAAA ...give the title a null value... (page 6-43 UWCG). Can also@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII be called "ti". ;~@@ AA Because multiple rules are appearing in the same clause, separate with a semi-colon. picture=}~@@ AAAAAAAAAA ...and do not define a picture. (page 6-40 UWCG). Can also be@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII called "pi". There is no need to place a semi-colon here as this is the last rule in this clause. }~@@ AA end the icon_rules{} clause. So, in summary, the rule icon_rules{ .* {title=;picture=} }@@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA or ic{ .* {ti=;pi=} }@@ AAAAAAAAAAAAAAAAAA translates to For all files that start with '.' give the title a null value@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII and do not define a picture.@@ IIIIIIIIIIIIIIIIIIIIIIIIIIII If no picture and no title are defined, the icon doesn't appear on the desktop and hence no actions can be performed on it by the user. .PA Example 2: How can I prevent all users accessing the parent@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII directory in directory windows?@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII Because this rule must apply to all users, the logical place to make the change is in the System Rule File. The method of solution to follow is similar to Example 1 above, except that because we want "all files that are called '..' and are directories" one should consider "Classes" in the icon_rules{} clause: icon_rules{ ../D{ti=;pi=} }@@ AAAAAAAAAAAAAAAAAAAAAAAAAAA ..~@@ AAA The name of a parent directory in Unix is "..". /D~@@ AAA First, because the Pattern is not an absolute pattern ("If the pattern begins with a / it specifies an absolute pattern; otherwise it is a relative pattern" (page 6-31 UWCG)) the '/' to separate the Class from the Pattern can come immediately after the Pattern (page 6-31 UWCG). Classes are used to represent the properties of files in a concise form. "D" defines that the file is a directory, but note that "D" is read as "DXANWVKHMO": to understand why refer to (pages 6-32 to 6-34 UWCG). So, in summary, the rule icon_rules{ ../D {title=;picture=} }@@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA translates to For all files that are called ".." and are directories set the@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII title to be null and do not display a picture.@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII .PA Example on how to prevent users doing certain actions. .....L..T.......T.......T.......T.......T.......T.......T.......T...J I have a user who thinks that to view the rules of an icon, they@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII should drag-and-drop this icon onto the rules icon. If the icon@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII is dragged onto the .xdtuserinfo icon, xdt complains that there@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII are "No rules defined for this action" in an Information window,@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII which I can live with. But if the icon is dragged onto the@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII .xdtdir Directory Rule File icon then xdt interprets this as a@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII copy operation and the file that this icon represents gets@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII copied into the .xdtdir directory. How can I prevent this oper­@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII ation from being performed just for this user?@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII Really the rules should be tailored so that the .xdtdir icon is not displayed in the directory window, and if it is, this assumes the user is experienced enough not to perform the copy operation deliberately. But for the purpose of this practical example, a rule can be defined in the user's rule file which states:~ For all directories called '.xdtdir', cause any drag operations@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII to be denied with the message 'This action is not allowed.' in@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII an Information box.@@ IIIIIIIIIIIIIIIIIII icon_rules{@@ AAAAAAAAAAA .xdtdir/D {~@@ AAAAAAAAAAA For all directories called '.xdtdir',...~@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII trigger_action : d* {~@@ AAAAAAAAAAAAAAAAAAAAA ...cause any drag operations...@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII actions {b: mfyi "You cannot view rules that way"}~@@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ...to be denied with the message 'This action is not allowed.'@@ IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII in an Information box.@@ IIIIIIIIIIIIIIIIIIIIII }}}@@ AAA In summary, the rule is .....L..T.......T.......T.......T.......T.......T.......T.......T..........J icon_rules{~@@ AAAAAAAAAAAA .xdtdir/D{~@@ AAAAAAAAAAAAAA trigger_action : d*{~@@ AAAAAAAAAAAAAAAAAAAAAAAAAAA actions{~@@ AAAAAAAAAAAAAAAAAA b: mfyi "You cannot view rules this way"~@@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA }~@@ AAAAAAAAAAA }~@@ AAAAAAAA }~@@ AAAAA }@@ A