# Implementation 

We outline the approach taken to implementing the new features required
to implement our domain-specific resource management architecture.
Specifically, we describe:

-   Services for the creation, configuring, and management of accounts
    and account groups

-   Extensions to GRAM allowing it to work with sandboxes created in
    this way

The current implementation makes the following assumptions:

The initial account and deployment domain is defined as one machine,

Tested for master/sub account relationship

## Management of Dynamic Accounts and Account Groups

The RM agent design requires the existence of two kinds of entities:
privileged entities (agents) and ordinary entities (e.g., clients that
submit to those agents). In order to ensure both positive and negative
enforcement of actions on those entities we will provide mechanisms
mapping them to sandboxes with different privilege levels: master
accounts and subsidiary accounts.

Specifically, the master account should be able to start and manage jobs
in those ordinary accounts and give file ownership on files owned by the
master account to those accounts so that only the owner account has
read/write privileges on those files. We assume that a group of accounts
has only one master and that a master account cannot itself be an
ordinary account (i.e., have a master).

The accounts are represented as WS-Resources, thus allowing for
inspection, lifetime management, property management (only quota at this
point), and policy management (including access policy and management of
account relationships). To support this, we implement two services per
account domain: dynamic account factory (DAF) and dynamic account
service (DAS).

The DAF implements the following methods:

-   create Account, where the inputs are account request (time to live,
    quota, list of DNs that can submit to the account via master,
    whether a master or subsidiary account, and optionally either a list
    of subsidiary accounts or a pointer to master account). The output
    is an EPR to the account resource

-   createAccountSet, where the input is an array of account requests
    comprising of input for a single master account and a set a
    subsidiary accounts for that master. The output is an AccountSetEPR
    data type (which contains a master EPR and set of subsidiary EPRs).
    First the subsidiary accounts are created and then the master
    account with EPR to each of the subsidiary accounts.

Although better authorization methods would in principle be possible,
currently both calls are authorized via access control list (ACL).

The DAFS at start up creates a WS-Resource for each configured creation
mechanism. This resource is used to carry state information relevant to
the creation mechanism, like default time to live of accounts created,
hosts it can create accounts and so on. In this implementation, two
creation mechanisms are installed by default: Unix accounts and a test
creation mechanism. The former uses underlying system commands in Unix
to manipulate accounts, while the latter was a test mechanism that can
be used to test the resource state management and lifetime management
features of the service. The implementation is extensible to accommodate
more different creation methods potentially including account leasing
and others.

When account creation request is received by DAFS, the following actions
happen. First, a WS-Resource is created for the account using the
WS-Resource that represents the creation mechanism, which creates an
account in a testbed-specific way. In the case of this implementation ir
will be either a Unix system call to create new user account or a test
resource that just creates a Java Object for the account. In the case of
Unix accounts, a new Unix group is assigned to each newly created
account, and the master of this account is added to that group (this is
used to implement delegating file ownership).

In the second configuration step, execution policies are configured for
the account as follows. The resource (host) level gridmap file (used by
GRAM ) is modified to allow execution in this account by the entity that
created the account. Also, the list of DNs that can submit to the
account via an RM agent is added to the RM agent ACL. We will have to
allow the policy behavior to be easily extensible in the future.

Each resource that represents the account has a lifetime associated with
it (either the requested lifetime or default lifetime for the creation
mechanism). When the end of life is reached, the account is
automatically shut down and the same steps as described in the
deleteAccount bullet below is performed.

The EPR returned by the created account can be used to access the
WS-Resource created for the account through the DAS. The DAS implements
the following methods:

-   deleteAccount: account termination involves killing all processes
    running under the account (using GRAM to avoid surprises) cleaning
    the system, deleting the account and all relevant information from
    the system, and adjusting the gridmapfile.This again should be
    configurable in the future.

-   setQuota/getQuota: manage quota settings on an account

-   AddAuthzIdentity/removeAuthzIdentity: add or remove entities
    authorized to use this account according to the RM ACL

-   addAccounttoGroup/removeAccountFromGroup: add/remove the account to
    group with a specified master (master specified as input EPR),

-   introspection: local account name, access policies and execution
    policies.

All account creation and termination operations are currently not logged
by GT4 logging mechanisms because GT4 logging has not been implemented
yet.

## Extensions to GRAM

Creating multiple accounts will allow an entity (such as a VO agent) to
create several accounts and submit as a chosen account. In order to
allow an authorized Grid user to gain access as a specific local
identity (master or subsidiary account) it is necessary to extend GRAM
(pre-WS GRAM in our case) to add this "submit as" functionality. In
addition, to allow for dynamic modifications, it is also necessary to
add locking to the gridmapfile (?).

Another required extension is the ability for a client to delegate a
chosen set of credentials to an executing job. This is done to support a
scenario in which a client asks a VO agent to run a program on its
behalf: the VO agent may have to use its privilege to start a program,
but it is the original client's credentials that need to be delegated to
that program.

We have extended GRAM to implement those functionalities

## Controlling Access to Resources

We implement file access control functions by using Unix groups. Each
account is associated with a unique group that the master account is
also a member of. When a file is first created, it is initially owned by
the master account, which can then change the group to the group
associated with a given account thereby giving the account access. The
scalability of this solution is limited by the number of groups that a
single account can belong to (currently to 16; although this could
probably be extended it is not clear how high and there will always be a
hard limit).

## Prototype VO Agent

To demonstrate how the capabilities described above can be used to
implement a VO agents, we implemented a very simple VO agent program.

The VO agent is installed in a master account (see 1.1) with MASTER DN
master credentials. The account is configured with an agent-specific
executable and a set of files owned by the agent.

The agent implements a simple interface whereby a client can ask the
agent to execute N instances of an executable in separate accounts as
long as N is below a certain number (this is a "throttling" policy
implemented by the agent)

In the simple demo program a VO agent takes a program name and the The
gridmapfile on the resource is initially configured with execution
access for the clients and the master's DN. As the accounts get created,
the gridmapfile is modified to include entries allowing the entity
creating them (the master DN) to map to those accounts (see section
1.1).

On receiving an eligible request (N\<limit), the VO agent first creates
N accounts to run in noting the client's association with these accounts
in VO agent's ACL file (see section 1.1). Then, the agent gives access
to a specific file to each of those accounts by changing the group
ownership of the file to the unique group associated with this account
(see section 1.3). Then the agent starts jobs in each of the newly
created accounts as requested using master credentials and the GRAM
"submit as" feature (see section 1.2). Then it delegates the client's
credentials to the jobs. The jobs write to the files that were made
available to them. After the jobs finish, the agent changes file
permissions back and the accounts are deleted. When the servicing of
request is finished the VO agent returns control to the client.

The VO agent's interface to the client could be potentially extended to
include more of a dialogue: for example instead of deleting accounts,
the VO agent could return a handle to an account to the client and use
the account access mechanisms to enable different entities to execute in
those accounts. This is based on specific needs and has not currently
been implemented.