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 reserach 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 can 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 achieve this goal of protecting system security, ARSC staff reserve the right to routinely examine certain features of user accounts (such as environment file permissions) and inactivate and examine the contents of user accounts without prior notification in the event of a suspected security incident.
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 establised pursuant to the 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
Because of the potential security risk presented by environment, or "dot" files and directories, ARSC routinely checks the 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, because of the seriousness of exposure some permissions can impose on the entire system, the user's account may be inactivated 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 can be granted three access types: 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 manpage (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 are suspicious 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 ensuring their private key is not accessible by other users. Private keys should only be generated and stored on systems which you trust.
- ARSC encourages the use of a non-null 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 the presence of the file(s).
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. This is accomplished via regular on-site backups of home directories and the $ARCHIVE filesystem. 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 or $SCRATCH directories are 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) shoud 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 from accidental deletion or corruption is available for backed up filesystems. 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.
Data Storage Management
Please read the ARSC Storage Management page for detailed information regarding the best use of storage resource use and management 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 users 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 address 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 the Viz labs should exercise sound judgement in protecting 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 to gain 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.