When you get a new hub, by default everyone gets a workspace and can submit jobs to
your attached cluster(s). This means that the user can run many different
commands both on your hub and on your clusters, in addition to 
the software applications your hub provides. 

For some sites, this causes security issues, so you may wish to limit access to the 
software the user can execute and the clusters he or she can submit jobs too. Usually 
only tool developers need workspace access.

== Limiting Workspace Access ==

The first thing to do is to ask HUBzero staff to '''change the default to not provide workspace
access'''. 

The user will still be able to run portal applications and pick up their output files
by sftp or webdav.

Then, to give users a workspace:

 * login to the Joomla interface
 * select Components/Groups
 * locate the app-workspace (Workspace Development) group, click Total Members
 * add users as appropriate


== Limiting Submit Access ==

There are several aspects to submit access control.

 # Allow a user run a HUB application that gets submitted 
    as a job to a cluster.
 # Allow a user run standard unix and shell commands as jobs submitted
   to a cluster, even something as simple as  '''echo hello'''
 # Allow a user stage his or her own executable to a cluster and run it.

=== Getting Started ===
To set access control, you will need to be a member of the group name ''apps''.
Membership will give you write permissions
on the files ''/opt/submit/sites.dat'' and ''/opt/submit/tools.dat'' and on your HUB. 
You can add yourself through the Joomla interface as described above. It can take
a day before the change propagates through the system.

It is a good default to limit the user to running HUB applications.
To limit a user to only (1), ask the submit rules be tightened so that if a user is not in group submit they can '''only run staged applications or executables from ''/apps/'''''. These executables are under control
of group apps thus providing some oversight for the application code.

==== To limit the clusters a user can run on ==== 

Whether running submit from a workspace or HUB applications, you
may want to limit the supercomputing sites that a user can run on.
You first need to create a group for each cluster. For example, 
the hpc2.org HUB has three groups: ''ccr'' (Center for Computational Research),
''ccni'' (Computational Center for Nanotechnology Innovations) and 
''sbbnl'' (Stony Brook/Brookhaven National Lab).

Next, edit sites.dat

For each cluster, add a line to restrict use of the application to the 
site group associated with the cluster, e.g. '''restrictedToGroups = ccr'''

Then you can invite the user to join groups for clusters on which 
she'll be able to run applications.

=== To limit where the user can run applications ===

An application may be run at more than one site, but you wish to direct a user's
run to one particular site. 

You will need to edit ''/opt/submit/tools.dat'' to set each execution to match one site.
Below is an example. If the user is in group ''ccni'', lammps will run on ccni's opteron cluster.
If the user is in group ''ccr'', lammps will run on ccr's cluster.

lammps<br/>
destinations = u2-grid<br/>
executablePath = lmp_linux<br/>
remoteManager = u2-grid_lammps<br/>
restrictedToGroups = ccr<br/>

lammps<br/>
destinations = rpi-opteron<br/>
executablePath = ${HOME}/apps/lammps/bin/lmp_opteron<br/>
remoteManager = rpi-opteron_lammps<br/>
restrictedToGroups = ccni<br/>


=== To prevent a user from running arbitrary shell commands on a cluster through submit ===

Users who have a workspace can submit jobs to clusters.
Ask the HUB staff to tighten the range of submit jobs so 
restrictions by user or group can be specified for sites as well as
tools. (The keywords and parameters will be specified in sites.dat in 
the same fashion as tools.dat.) 

Open the file '' /opt/submit/sites.dat'' on your HUB.
For each cluster name, add or change the setting '''arbitraryExecutableAllowed''' to '''False'''.

Then you can add users to the group ''submit''.