two-level systems (overview)

30
1 Part 5. Permission Rules for Two- Level Systems Controlling access (visibility or scope) of static references. Analogous to “private” in C/C++/Java.

Upload: tovi

Post on 06-Jan-2016

20 views

Category:

Documents


0 download

DESCRIPTION

Part 5. Permission Rules for Two-Level Systems Controlling access (visibility or scope) of static references. Analogous to “private” in C/C++/Java. Two-Level Systems (Overview). Two levels (not counting root) “Modules” contain resources Leaves are “resources”, e.g., functions, variables - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Two-Level Systems (Overview)

1

Part 5.Permission Rules for Two-Level Systems

Controlling access (visibility or scope) of static references. Analogous to “private” in C/C++/Java.

Page 2: Two-Level Systems (Overview)

2

Two-Level Systems (Overview)Two levels (not counting root)

“Modules” contain resourcesLeaves are “resources”, e.g., functions, variables

An example systemSome example permission rulesets

zxy

m n

system

Modules: m, n

Resources: x, y, z…

Modules could be files. Resources could be functions and variables.

Page 3: Two-Level Systems (Overview)

3

Example Two-Level System: Three Representations

system

x y z

m n

U

U

zx

y

m n

system

U

U

II

C = contain, U = use, I = import

Think of U (use) as “call”, “access variable”, etc.

Think of I (import) as permission to use.

Top level: Modules (m, n)

Bottom level: Resources (x, y, z)

c

c

c

c c

“Import” is sometimes called “Transport”

Page 4: Two-Level Systems (Overview)

4

“Import” Ruleset (2-Levels)

x can use y if x and y are siblings, or if x’s parent imports y’s parent

x U y (x S y or m,n x P m I n C y) U S P o I o C, I S

zx

y

m nU

U

I

C = contain, P = parent, S = sibling, U = use, I = import

Constraint: Modules import only modules and resources use only resources

Page 5: Two-Level Systems (Overview)

5

“Export” Ruleset (2-Levels)

x can use y if x and y are siblings, or if x’s parent’s sibling exports y

x U y x S y or j,k x P j S k E y U S P o S o E, E C

zx

y

m nU

U

E

Constraint: Resources use only resources

“Export” is much like “public” in Java/C++.

Page 6: Two-Level Systems (Overview)

6

“Import-Export” Ruleset (2-Levels)

x can use y if x and y are siblings, or if x’s parent imports y’s parent, who exports y

x U y x S y or m,n x P m I n E y U S P o I o E , I S , E C

zx

y

m nU

U

EI

Constraint: Modules import only modules and resources use only resources

Page 7: Two-Level Systems (Overview)

7

“Buy” Ruleset (2-Levels)

x can use y if x and y are siblings, or if x buys for its parent, whose sibling is y’s parent

x U y x S y or m,n x B m S n C y U S B o S o C , B P

zx

y

m nU

U

B

Determines which resources can “buy” or “reach” outside their modules.

Page 8: Two-Level Systems (Overview)

8

x can use y if x and y are siblings, or if x imports y’s parent

w can import n if w and n are siblings, or if w’s parent imports n

U S I o C, I S P o I

Variation of “Import” Ruleset (2-Levels)

zx

y

m n

UU

I

Rules much like this are used in Euclid and Turing languages.

I

Page 9: Two-Level Systems (Overview)

9

Predefine: Mod = id(setOfModules) Constraint: Modules import only sibling

modules x I y x Mod o S o Mod y I Mod o S o Mod

Using ID (Self-Loop) Relations

zx

y

m nI

Many other possible rules, e.g., “Import-Buy”

Mod Mod

Page 10: Two-Level Systems (Overview)

10

Various Two-Level RulesetsRuleset Name Rules

Buy U S B o S o C, B P

Import U S P o I o C, I S

Export U S P o S o E, E C

Buy-Import U S B o I o C, B P, I S

Import-Export U S P o I o E, I S, E C

Buy-Import-Export U S B o I o E, B P, I S, E C

Constraints: Leaf2Leaf(U), Mod2Mod(I)

Page 11: Two-Level Systems (Overview)

11

Part 5b.Permission Rules for Multi-Level Systems

Trees not necessarily balanced“Use” edges not necessarily from leaf to leaf

Page 12: Two-Level Systems (Overview)

12

Example Ruleset: “Whole Import-Export”

A node may export its children.A node may import its siblings. Also, it may import what its parents import.A node may use its siblings and what they export recursively. Also, it may use what its parents import, as well as what they export recursively.

Similar to permission rules used in Turing and Euclid languages

Page 13: Two-Level Systems (Overview)

13

Whole Import-Export Ruleset

Ia

x

b

c

y

dI

U

E

E

• Use U S o E* P o I o E* • Import I S P o I• Export E C

Each permitting edge is a tube of the permitted edge

Page 14: Two-Level Systems (Overview)

14

Selective Buy-Export Ruleset

a

x

b

c

y

d

U E

Evw

B

B

PB PB S

CEEC

U

Selective Buy-ExportU B* o S o E* B B* o P E C o E*

“Tubular Permission”: Each permitting edge is a tube of the permitted edge

Page 15: Two-Level Systems (Overview)

15

Example Multi-Level Rulesets

Selective Import-Export rulesetE C o E*

I S o E* P o I o E*

U S o E* P o I o E*

Tube rulesetT S P o T P o T o C T o C

Whole Buy-Sell rulesetE CB PU B* o S o E*

[Holt tech report 345 ‘96, Mancoridis thesis ‘96] ?

Page 16: Two-Level Systems (Overview)

16

Iactual = I (these actually occur in graph)

Iallowed = S o E* P o I o E* (these are computed)

Iconforming= I Iallowed

Iviolation = I - Iallowed

Igratuitous = Iallowed - I

Violating, Conforming & Gratuitous Edges

[See also Murphy’s “reflexion” model ‘95]

Iactual = I Iallowed

Iviolating Igratuitous

Iconforming

To satisfy requirement: Iactual Iallowed

• Bottom up: Increase parent’s Iactual

• Top Down: Decrease childrens’ Iactual

Page 17: Two-Level Systems (Overview)

17

Part 6.Sum-of-Products (SoP) Permission Rules

Page 18: Two-Level Systems (Overview)

18

Rule 1: I S P o IRule 2: E CRule 3: U S o E* P o I o E*

SoP: Example Ruleset

Example ruleset hasThree variables (LHS’s): I, E and UThree constants: S, P and CThree rules (one for each variable I, E and U)

The right hand side for rule 1 (S P o I) is the “sum” (union) of two “products” (S and P o I)Rule 2 uses reflexive transitive closure (*)

Page 19: Two-Level Systems (Overview)

19

SoP: Basic Vocabulary

The RHS of each SoP rule is a “sum” of “products”, e.g., in

I S P o I• RHS is the “sum” of S and P o I• P o I is a “product”

In other words: • Each RHS is a set of simple “path expressions”• SoP = Sum-of-Products = Set-of-Paths

Page 20: Two-Level Systems (Overview)

20

Formal Definition: SoP RulesetDef. A Sum-of-Products (SoP) ruleset R consists of a non-

empty set of rules each of the formV P1 P2 … Pj where i 0.

Each Pi is a product and is of the formr1 o r2 o … rk where k 1

About transitive closure TC. In much of the following, we disallow Transitive Closure (suffix + and *) on RHS to make our presentation simpler. In many cases below, transitive closure can occur in an RHS without changing the results. In many cases, algebraic expressions, involving parentheses, can be incorporated, as long as non-monotonic operators such as set subtraction and complement are not allowed.

Page 21: Two-Level Systems (Overview)

21

Formal Definition: Symbols, Constants and VariablesDef. Each symbol is a constant or a variable. Consider

an arbitrary rule in an SoP ruleset: V P1 P2 … Pj

where each Pi is a product of the formr1 o r2 o … rk

Each ri and each V is called a symbol. If the symbol is directly defined in terms of the tree (e.g., C, ID, P, S), it is a constant. Otherwise the symbol is a variable. A variable is sometimes called a type. The left hand side (V) of a rule must not be a constant. Thus each left hand side (V) is a variable.

Each variable V can appear on the left side of at most in one rule.

Page 22: Two-Level Systems (Overview)

22

Formal Definition: Empty SumsA sum can be empty. In principle, a rule’s sum

P1 P2 … Pj

can contain zero productions, which case the rule is taken to mean V empty

where empty is the set of zero edges.If a variable W appears in a product but not

explicitly on the left hand side of a rule, then we assume that there is a rule of the form:W empty

We could disallow empty sums, with little change in results.

Page 23: Two-Level Systems (Overview)

23

Def. Consider SoP ruleset R consisting of rules of the formV P1 P2 … Pj A particular Pi is: r1 o r2 o … o rk

Each V with each of its products Pi is called a production, written

V R Pi Where Pi is: r1 o r2 o … o rk

V R (r1 r2 … rk) We say V depends on sequence (r1 r2 … rk) according to ruleset R

V (r1 r2 … rk) When R is clear from context we simply say V depends on the sequence.

We also define (for each V and each ri)V R ri We say V depends on symbol ri

according to ruleset RV ri When R is clear from context we say

simply V depends on symbol ri

Formal Definition: Productions and Dependencies

We can give an SoP ruleset by giving a list of its productions.

Page 24: Two-Level Systems (Overview)

24

Formal Definition: The Tree (The NBA Hierarchy)There is a hierarchy defined by tree T, which can be thought

of as the containment tree of an NBA model.Def. The tree (hierarchy) T is defined by a set of nodes with

directed edges called C:N = non-empty set of nodes (vertices)C N X N (C for Contain or for Child)

T forms a directed tree, so:There are no cycles formed by the C edges There is a distinguished node called the root wuch that no node contains the root, i.e., the root has not parentEach node except the root is contained by exactly one other node, i.e., each non-root node has a single parent

There will be variable edges, e.g., V and W edges, added to the tree.

Page 25: Two-Level Systems (Overview)

25

Formal Definition: StatesDef. Assume

(1) tree T which defines node set N(2) ruleset R which defines a set of variables (relations)

v = {v1, v2, …}

Corresponding to each variable vi is a set of edges

ei N X N, ei = (xi, yi) where xi and yi are nodesA state (or graph) s is the set of these named sets of edges

s = {v1 : e1, v2 : e2, …}An alternate approach considers that s is a set of triples:

s N X v X NIn the alternate approach:

s = { (x1 v1 y1), (x2 v2 y2), … }

where x1, x2, … , y1, y2, … are nodes and v1, v2, … are variables (relations).

Each state is an NBA model

Page 26: Two-Level Systems (Overview)

26

Example ruleset R:Rule 1. I S P o IRule 2. E CRule 3. U S o E* P o I o E*

Assume there is a tree T that connects a set of nodes.State s consists of sets of directed edges each associated with

a variable (I, E and U) from the ruleset. Each such edge connects two nodes in the tree.

Def. State s is legal, written L(s), when all rules in the ruleset are satisfied (rules are interepreted using Tarski binary algebra).

Legality of States in Terms of Ruleset R and Tree T

This example uses transitive closure, although SoP as defined disallows TC. However, most results given here can be generalized to allow TC.

Page 27: Two-Level Systems (Overview)

27

Example: Two Alternate Representations of StatesExample ruleset: Has three variables: I, E and U.

State s can be represented as either (a) n sets of pairs (one for each variable), e.g.,

s = { I : {(a,b), (b,c)}, E : {(a,d)}, U : {(a,d)} }, or (b) a single set of triples, e.g.,

s = { (a I b), (b I c), (a E d), (a U d) }

Page 28: Two-Level Systems (Overview)

28

Legality of States in Terms of Permission Function f(s)Def. Permission function f(s) maps each state s (a set of triples) to

a statef : Q Q

Q is the set of all states. Function f(s) is defined as the set of triples allowed by s.

Example. In the ruleset with variables I, E and U, f(s) consists ofI triples as computed by I’s products (S, P o I), E triples as computed by E’s products (one E tuple for each C tuple), U triples as computed by U’s products (U S o E*, P o I o E*)

Def. State s is legal, that is, L(s) is true, when s contains only triples allowed by f:L(s) =def s f (s)

Worry: This could be clearer??

Page 29: Two-Level Systems (Overview)

29

Monotonic Permission FunctionFunction f is monotonic:

s s’ f(s) f(s’)

This means: Adding triples to a graph (state) can make more triples legal and cannot make existing legal triples illegal.

SoP rulesets are inherently monotonic, because each right hand side of a rule contains only monotonic operators, namely, “sum” (union) and “product” (composition).

Page 30: Two-Level Systems (Overview)

30

Properties Common to Many Example SoP Rulesets

Graph is legal (Lf) if it is a prefixpoint of fLf (s) =def s f(s)

Note: when s f(s), s is called a prefixpoint.

Permission function f is monotonicLegality is piecewise defined (graph is legal iff each triple in it is legal)A graph may permit more triples to be added to itLegal graphs are constructive, i.e., can be built step-by-step from legal subgraphs

What permission rules have these properties??