![](bg7.png)
two procedures called Membership and JuniorList. Membership procedure
allows us to have all assigned roles to a user and JuniorList procedure returns all
junior roles to a specified role by walking down the hierarchy. This grant algorithm
checks can-assign table and AT-SET table to enforce constrained user assignment.
4.1 Implementation Details
Every account in Linux contains a group membership list indicating which groups
the account belongs to. Users belonging to a group are explicitly enumerated in ei-
ther /etc/passwd(for the primary group) or /etc/group (for secondary groups).
Many commercial database management systems, such as Informix, Oracle and Sybase,
provide facilities for hierarchical groups (or roles). Commercial operating systems,
however, provide limited facilities at best for this purpose.
To maintain the group hierarchy we use the file /etc/grouphr to store the chil-
dren and parents of each group. The group hierarchy of Figure 1 is represented in
/etc/grouphr as shown in Table 1. The first column gives the group name, the
second column gives the (immediate) parent groups of that group, and the third column
gives the (immediate) children. The null symbol “−” means that the group has no par-
ent or child as the case may be. Using /etc/grouphr, we can find all seniors and
juniors for a group by respectively chasing the parents and children.
We say a user is an explicit member of a group if the user is explicitly designated
as a member of the group. A user is an implicit member of a group if the user is an ex-
plicit member of some senior group. To simulate a group hierarchy we use information
about explicit and implicit membership in /etc/group. If Alice belongs explicitly or
implicitly to a group she will be added to that group’s member list in /etc/group.
However, /etc/group is not sufficient to distinguish the case where Alice is both an
explicit and implicit member of some group from the case where she is only an implicit
member of the group. For this purpose we introduce another file /etc/explicit
that keeps information about explicit membership only.
In order to enforce separation of duty constraints, we maintains /etc/at
set
which includes conflicting roles. This table also can contain conflicting users and per-
missions. Table 2 illustrates how we can accommodate such sets to support constrained
user assignments.
There are two issues that need to be addressed in decentralized management of
group membership. Firstly we would like to control the groups that an administrative
group has authority over. Recall figures 1 and 2 which respectively show the regular and
administrative groups of our example. We would like to say, for example, that the PSO1
administrative group controls membership in project 1 groups, i.e., E1, PE1, QE1 and
PL1. Secondly, it is also important to control which users are eligible for membership
in these groups.
URA97 addresses these two issues respectively by means of a group range and a
prerequisite group or more generally a prerequisite condition. URA97 has a can
assign
relation which we store in the file /etc/can
assign. We put a colon between the
columns to indicate the boundary. Table 3 illustrates the general case of /etc/can
assign
with prerequisite conditions. Let us consider the PSO1 rows. The first row authorizes
PSO1 to assign users with prerequisite group ED into E1. The second one authorizes
19