- 48 Views
- Uploaded on
- Presentation posted in: General

Two-Level Systems (Overview)

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

- Two levels (not counting root)
- “Modules” contain resources
- Leaves are “resources”, e.g., functions, variables

- An example system
- Some example permission rulesets

system

m

n

Modules: m, n

Resources: x, y, z

…

z

x

y

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

system

I

m

n

U

z

x

U

y

Top level: Modules (m, n)

Bottom level: Resources (x, y, z)

system

c

c

I

m

n

c

c

c

U

x

y

z

U

C = contain, U = use, I = import

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

Think of I (import) as permission to use.

“Import” is sometimes called “Transport”

- 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

I

m

n

U

z

x

U

y

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

Constraint: Modules import only modules and resources use only resources

- 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

m

n

E

U

z

x

U

y

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

Constraint: Resources use only resources

- 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

I

m

n

E

U

z

x

U

y

Constraint: Modules import only modules and resources use only resources

- 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

m

n

B

U

z

x

U

y

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

- 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

I

m

n

I

z

x

U

U

y

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

- 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

Mod

Mod

I

m

n

z

x

y

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

Constraints: Leaf2Leaf(U), Mod2Mod(I)

- 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

I

a

c

E

b

d

I

E

x

U

y

- UseU S o E* P o I o E*
- ImportI S P o I
- ExportE C

Each permitting edge is a tube of the permitted edge

a

c

b

E

d

v

B

w

B

x

E

U

y

C

P

C

B

P

E

Selective Buy-Export

U B* o S o E*

B B* o P

E C o E*

S

B

E

U

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

Selective Import-Export ruleset

E C o E*

I S o E* P o I o E*

U S o E* P o I o E*

Tube ruleset

T S P o T P o T o C T o C

Whole Buy-Sell ruleset

E C

B P

U B* o S o E*

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

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

Iactual = I

Iallowed

Iviolating

Igratuitous

Iconforming

- To satisfy requirement: IactualIallowed
- Bottom up: Increase parent’s Iactual
- Top Down: Decrease childrens’ Iactual

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

- Example ruleset has
- Three variables (LHS’s): I, E and U
- Three constants: S, P and C
- Three 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 (*)

Rule 1: I S P o I

Rule 2: E C

Rule 3: U S o E* P o I o E*

- The RHS of each SoP rule is a “sum” of “products”, e.g., in
I SP 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

Def. A Sum-of-Products (SoP) ruleset R consists of a non-empty set of rules each of the form

V P1 P2 … Pj where i ³ 0.

Each Pi is a product and is of the form

r1 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.

Def. 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 form

r1 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.

A 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.

Def. Consider SoP ruleset R consisting of rules of the form

V 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 DR Pi Where Pi is: r1 o r2 o … o rk

V DR (r1 r2 … rk) We say V depends on sequence

(r1 r2 … rk) according to ruleset R

V D (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 dR ri We say V depends on symbol ri

according to ruleset R

V d ri When R is clear from context we say

simply V depends on symbol ri

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

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 parent
- Each 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.

Def. 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 nodes

A 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 N

In 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

Example ruleset R:

Rule 1. I S P o I

Rule 2. E C

Rule 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).

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

Example 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) }

Def. Permission function f(s) maps each state s (a set of triples) to a state

f : 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 of

I 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??

Function 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).

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

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

- Permission function f is monotonic
- Legality is piecewise defined (graph is legal iff each triple in it is legal)
- A graph maypermit more triples to be added to it
- Legal graphs are constructive, i.e., can be built step-by-step from legal subgraphs
What permission rules have these properties??