ARSC User Policies
ARSC users are required to abide by current ARSC policies governing systems and resources operated by ARSC. Use of ARSC resources is subject to ARSC policy, University of Alaska Fairbanks regulations, University of Alaska and Regents Policies, and the State of Alaska and Federal laws.
The following policies apply to every person granted access to ARSC resources and should be reviewed on a regular basis.
- Login Shells
- Public Web Resources
- Publications and Citation Credit
- Security Policies
- Storage Policies
- System Downtimes
- System Generated E-mail
- Vizualization Laboratory Policies
***ARSC operates an unclassified and non-sensitive computing environment. Do not introduce classified or sensitive work on ARSC systems.***
The following login shells are available on ARSC systems:
- bash (Bourne-Again Shell)
- csh (C Shell)
- ksh (Korn Shell)
- tcsh (Turbo C Shell)
If you would like your default login shell changed, please contact User Support.
Public Web Resources
ARSC offers web services to current users in an effort to facilitate the distribution of research related content. For more information, read the ARSC Web Services page.
Publications and Citation Credit
All publications resulting from research supported by ARSC grants shall include the following credit:
"This work was supported in part by a grant of HPC resources from the Arctic Region Supercomputing Center at the University of Alaska Fairbanks."
Principal Investigators must submit a brief annual project renewal and report describing their project research objectives, computational methodology, results, significance of the research, and any publications or presentations resulting from the use of the ARSC resources.
Every user of ARSC systems may rightfully expect their programs, data, and documents stored on ARSC systems, to be: inaccessible by others, secure against arbitrary loss or alteration, and available for use at all times. To help protect system security and achieve this goal, ARSC staff reserve the right to routinely examine certain features of user accounts, such as environment file permissions. In the event of a sustepcted security incident, ARSC staff may deactivate and examine the contents of user accounts, without prior notification.
You may not share your account with anyone under any circumstances.
This policy ensures every user is solely responsible for all actions from within their account.
If you are interesting in allowing group members to read project data, Unix file and directory permissions should be granted group access. Please contact User Support for more information regarding changing group file and directory permissions.
Abuse of ARSC resources is a serious matter and is subject to immediate action. A perceived, attempted, or actual violation of standards, procedures, or guidelines pursuant with ARSC policies, may result in disciplinary action including the loss of system privileges and possibly legal prosecution in the case of criminal activity.
ARSC employs the following mechanisms to enforce its policies:
- Contacting the user via phone or email to ask them to correct the problem.
- Modifying the permissions on user's files or directories in response to a security violation.
- Inactivating accounts or disabling access to ARSC resources to ensure availability and security of the ARSC systems.
Environment (or "Dot") Files and Directories
Due to the potential security risk presented by environment, or "dot" files and directories, ARSC routinely checks file permissions set on all user environment files and directories. These files and directories are a prime target for attempts to compromise your account. Because of this, the user environment files must never be given group-writable or world-writable permissions. Also, symbolic links that take the place of dot files are not permitted. Further environment file restrictions are described in the table below.
When an environment file or directory permissions violation is discovered, ARSC will attempt to contact the user and request they modify the permissions. However, due to the serious nature of exposure, some permissions can impose upon the entire system, and the user's account may be deactivated without prior notification. The user must then contact User Support before the account will be reactivated.
|Environment File or Directory||Description||Allowed Permissions|
|.cshrc, .tcshrc, .kshrc, .login, .profile, .bashrc,.bash_login, .bash_profile, .bash_logout,.logout||csh/tcsh/ksh/bash initialization files, executed only on login or logout||400, 444, 600, or 644|
|.exrc||ex, vi resource file||400, 440, 600, or 640|
|.forward||mail forwarding file||400, 440, 600, or 640|
Files in this directory
|information for PGP encryption||
700, 600, or 400
|.shosts||file of trusted remote hosts and account names for SSH||400|
Files in this directory
|information for SSH encrypted connections||700, 600, 644, or 400|
|.Xauthority||Contains xauth magic cookies (keys) for authenticating X Window system requests to initiate processes on remote systems.||ONLY 600|
|.Xdefaults, .Xresources, .xinitrc, .xsession||X Window System environment files||400, 440, 600, or 640|
File and Directory Permissions
In Unix, file and directory permissions are granted three access modes: read, write, and execute.
These three access types can be applied to three different sets of users: file/directory owner, group members, all users on the system ("the world").
Most user files and directories should be set to read, write, and execute only by the file/directory owner. If data collaboration with group members is necessary, adding group read and execute permissions is sufficient to share data.
The following three restrictions must be followed regarding file and directory permissions on ARSC systems:
- Group and world-write permissions are not allowed on users' $HOME directories and files. Prohibiting the use of group and world-write permissions in $HOME maintains the integrity of user account logins and prevents the inadvertent denial of login access due to modifications to necessary system files stored in $HOME. World-write permissions are automatically removed from all user's $HOME files and directories on all ARSC systems.
- Setuid and setgid permissions are not allowed within users’ accounts. ARSC periodically runs tools to scan for the presence of setuid and setgid permissions on files. If found, we will contact the user and request they remove the permissions.
The following table lists recommended directory permissions. Use the “chmod” command to modify file permissions. View the chmod manual page (via the “man chmod” system command) to learn more about modifying file permissions.
|$CENTER with no file sharing||u+rwx,go-rwx|
|$CENTER with group file sharing||u+rwx,g+rx,o-rwx|
|$ARCHIVE with no file sharing||u+rwx,go-rwx|
|$ARCHIVE with group file sharing||u+rwx,g+rx,o-rwx|
Non-Printing Characters in File Names
Non-printing characters, such as ASCII codes for RETURN or DELETE, are occasionally introduced by accident into in file names. These characters present a low-level risk to system security and integity, and are not allowed.
Techniques for renaming, deleting, or accessing files containing non-printing characters in the filename are described in the ARSC "How-To" document, Removing Non-printing Characters from File Names .
ARSC uses University of Alaska (UA) systems for user authentication. Therefore, passwords used on ARSC systems are subject to UA password guidelines. We encourage the use of passwords at least 15 characters in length including multiple character classes.
Password Construction Recommendations:
- Length: Passwords should be at least fifteen characters in length.
- Composition: Passwords should us a mixture of alphabetic (A-Z,a-z), numeric (0-9), and non-alphabetic characters (digits, punctuation marks, symbols).
- Aging: Passwords should be change periodically. We recommend creating a new password every six months.
University of Alaska passwords may be changed using the ELMO webpage (https://elmo.alaska.edu).
If you suspect your password has been compromised, contact User Support immediately.
SSH Public Keys
On systems where the use of ssh public key authentication is allowed, each key entry in ~/.ssh/authorized_keys must specify a hostname using the authorized_keys " from= " clause. For example,
from="system.arsc.edu" ssh-rsa ...
The following policies must be followed when adding ssh public key authentication to your ARSC system login:
- Wildcards may not be used within a " from= " clause in the ~/.ssh/authorized_keys file without prior approval from User Support.
- ARSC periodically runs checks to verify the compliance of the contents of users' ~/.ssh/authorized_keys files.
- Sharing of private keys to allow another user to access your ARSC account is considered account sharing and is prohibited on ARSC systems.
- Permissions on the ~/.ssh/authorized_keys must abide by the dot files policy for .ssh directory files.
- Users of ssh public keys are responsible for their private keys and ensuring that they are not accessible by other users. Private keys should only be generated and stored on systems which you trust.
- ARSC encourages the use of passwords on ssh public keys to avoid use by unintended parties.
- The use of ssh-agents and ssh-add are allowed for one time password entry during a single login session.
Viruses and Malware
ARSC periodically scans systems for viruses and malware. If viruses or malware are detected on an ARSC system, ARSC will quarantine the suspected file(s) and notify the owner about their presence.
Do not attempt to break passwords, tamper with system files, access files in other users' directories without permission, or otherwise abuse the priviledges given to you with your ARSC account. Your privileges do not extend beyond the directories, files, and volumes which you rightfully own or to which you have been given permission to access.
Web-Based Mobile Code
ARSC attempts to ensure the highest availability and integrity of user data, through regular on-site backups of home directories and the $ARCHIVE file system. Beyond these efforts, users assume all responsibility for the loss of data stored on ARSC computer systems. Users with individual concerns about data availability should contact User Support.
ARSC user data in the $HOME and $ARCHIVE directories are backed up nightly. Backups are stored for 30 days.
The $CENTER directory is NOT backed up on ARSC systems. We strongly recommend saving copies of all important data to your $ARCHIVE directory.
ARSC operates an unclassified and non-sensitive computing environment. Do not introduce classified or sensitive work on ARSC systems. ARSC provides storage for data sets with scientific, educational, or cultural value. Sensitive information, such as server backups or personally identifiable information (i.e. social security numbers or birthdays), should NOT be stored on ARSC resources. Copyrighted materials are prohibited without proper authorization. Illegal content is prohibited.
If data on a backed up filesystem is lost, the data will be restored using the most recent backup available.
Changes made to the files since the most recent backup will be lost.
Restoration after accidental deletion or corruption is available for backed up file systems. Should restoration be needed, contact User Support as soon as possible for assistance. There is no guarantee deleted or corrupted files can be restored, but we will do our best to restore the data.
Inactive accounts and the data associated with them may be deleted from ARSC systems. Users not belonging to an active project are subject to account closure and data deletion.
Users who wish to maintain data in inactive accounts must make special arrangements with User Support.
Data may be transferred from an inactive account to the Principal Investigator of the project upon request. Please contact User Support for more information.
Temporary Storage and Purging
Data in the global temporary filesystem, $CENTER, is intended for short-term use and should be considered temporary. Data should reside in $CENTER only if needed or produced by a running, queued, or recently completed job or application. ARSC intends to maintain suitable available space in the $CENTER filesystem for new data to be created by running jobs or applications. As soon as the files in this filesystem are no longer actively used, they should be removed or migrated to $ARCHIVE if retention is required.
Because of the working-directory nature of the $CENTER global temporary filesystem, files are automatically removed on a regular basis.
File removal is based on time since last use. Files which have not been accessed (created, modified, or read) in the past 30 days are eligible for removal. Automatic file removal may be temporarily discontinued if under 50% of the filesystem is filled.
Automated backups are NOT performed on the $CENTER global temporary filesystem. While every effort has been made to assure files in $CENTER are accessible and available, files are unlikely to be recoverable in the event of multiple disk failures in a short time frame.
In the event of automated file removal, files are NOT recoverable. Therefore, users should back up important files to long term storage (for example $ARCHIVE).
Lists of files removed are available in /center/w/purgeList/username. No user notification will be made when files become eligible for removal or are removed.
Modification of file timestamp information, data, or metadata for the sole purpose of bypassing the automated file removal tool is prohibited.
If the global temporary filesystem is nearing capacity, User Support may contact users to request data removal. No user response to a request within 36 hours indicates User Support has permission to manually remove the data. If the filesystem runs out of or gets critically low on space, ALL data in $CENTER is subject to manual removal regardless of its age.
Users with needs or situations which conflict with the above policy should contact User Support to discuss available alternatives. Additionally, for help automatically migrating or backing up files in the global scratch filesystem, contact User Support.
Data Storage Management
Please read the ARSC Storage Management page for detailed information regarding the best use of storage resources at ARSC.
ARSC prioritizes the availability of its resources to the ARSC User community. Periodically the ARSC systems will be taken offline for scheduled or unscheduled maintenance. Users will be notified in advance prior to all scheduled maintenance downtimes. It is the responsibility of the user to ensure the recoverability of unexpected lost jobs or data in the event of an unscheduled downtime.
System Generated E-Mail
ARSC provides a ~/.forward file for users on each system. When the system generates an email, the message will be forwarded to email addresses listed in the .foward file. It is the user's responsibility to update the .forward file beyond the initial user account creation.
Visualization Laboratory Policies
ARSC hosts visualization laboratories (viz labs) on the UAF campus. These labs contain Apple Macintosh computers and/or Linux workstations. As with all ARSC resources, access is a privilege.
Users of viz labs should exercise sound judgement to protect these resources. Appropriate resource protection measures and policies include, but are not limited to, the following:
- Access to the ARSC viz labs is controlled via UAF Polar Express access. Users with a valid ARSC system ID and current Polar Express card may be given Polar Express access to the ARSC viz labs upon request.
- Sharing access to the ARSC viz labs is not allowed under any circumstances. If you are approached with a request to allow someone entry to the lab, deny the request and recommend the person contact User Support for assistance.
- Physical console logins take priority over remote logins.
- Consume food and beverages outside the lab only.
- Use the printing resources conservatively and wisely.
- Maintain a clean work environment by removing all personal items, materials, and refuse at the end of your session.
- Leave all computer equipment turned on.
- If you exit the lab temporarily, lock the screen on the computer before leaving the lab.
- Terminate your session by logging out when leaving the lab for longer periods of time.
- ARSC may disconnect idle terminal sessions to minimize the exposure of remote login sessions to security risks.
- Ensure the lab door closes and latches behind you after exiting (especially if the lab is unoccupied following your departure).
- Report all hardware, software, and environmental problems to User Support.
NOTE: Violation of these policies may result in the loss of access to ARSC resources.