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]
destinations = u2-grid
executablePath = lmp_linux
remoteManager = u2-grid_lammps
restrictedToGroups = ccr
[lammps]
destinations = rpi-opteron
executablePath = ${HOME}/apps/lammps/bin/lmp_opteron
remoteManager = rpi-opteron_lammps
restrictedToGroups = ccni
=== 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''.