User Agreement
This document details the rules governing user processes, files, and behavior on University IT-maintained general computing UNIX systems. It also describes some of your rights as a user on the system.
The document is a bit long, and a bit technical for those new to UNIX systems, but it is important that you read this and understand the contents. The UNIX consultants in University IT (IT Center, River Campus) are an excellent source of help; they will be more than willing to help you understand and comply with the recommendations and regulations in this document.
Why do we have these rules? We want to maintain a useful and responsive system for all users. Our primary concerns are to provide this service to researchers and students in classes, and to maintain campus-wide services such as DNS, news, web pages, and e-mail. These rules are enforced to help us meet this goal.
Use of your account indicates acceptance of these rules, and your agreement to abide by them.
NOTICE: Any activity which would violate, or could cause a violation of, existing Federal or state laws is forbidden by University IT policy.
Sections
- User Processes
-
Rules and guidelines related to programs you may execute
- User Files
-
Rules and guidelines related to files in your account, and the legal contents of system configuration files
- User Identity
-
Rules and guidelines related to user identification and misrepresentation.
- Web Policies
-
Rules and guidelines related to having a personal web page on Mail
- User Rights
-
Your legal and explicit rights as a user of University IT UNIX systems
- Password Reset Policies and Procedures
-
Procedures for resetting user passwords
- Closing/Expiring Accounts on University IT UNIX systems
-
University IT Policies for how accounts are closed on University IT UNIX systems.
- Logging into your account from off-campus
-
Using your account from off-campus and running the away command.
- System Downtime Policy
-
The times and conditions under which University IT UNIX systems may not be available for use
- Violating University Computing Regulations
-
The times when your account could be made unavailable to you if you violate University computing regulations.
- Collaborative Lock Policy
-
The times and conditions under which University IT may need to make your accounts unavailable.
- System Outage Notification Policy
-
Procedures to follow in case of problems with University IT UNIX systems
- Mail Message Size Limitations
-
The maximum size of a mail message users can send and receive on Mail.
- POP/IMAP mail access from outside rochester.edu
-
POP and IMAP access from outside rochester.edu network not allowed.
- Automatically Checking POP Mail
-
Limits on automatically checking mail through your POP client
In this section:
Why do we choose to terminate jobs, and how do we do so? We get automated reports on system/user processes, and the report generator has an idea of what is good and what is bad. We get reports on the "bad" processes. Any process that has become a "child of init," that is, whose parent process is process id number 1, is suspect. This normally happens when you leave a job running when you logout, and is not really a bad thing if the job was properly placed in the background, with I/O correctly redirected. However, we often see tip(1), mail(1), and rn(1ucc) processes either running or stopped, or in interactive wait (IW) that have become children of init. These kind of processes are detached (in VMS terms) and cannot be re-attached. You can never get back to them, or make use of what they are doing (if anything). Our response with this kind of process is to kill it and send a note to the user who owned the process. This happens so often, we keep a form letter, with some standard suggestions (all polite, we hope).
Certain types of processes (for example, make(1) or sas(1ucc)) can run in the background, and be left running when the user logs out (and hence are children of init), and can perform useful work for the user. A large make may take a long time, and not everyone wants to watch the make in progress. Unless these programs appear to be hung (inactive for a long time, not accumulating any CPU, waiting for interactive input), we will generally let them run. However, long-running processes should be 'niced' to a lower priority level (see nice(1) and renice(1)).
Any processes tying up limited resources for a long time will be terminated as well.
Another type of job that falls into this category is the result of poor programming -- jobs that open many files on an NFS mounted file system and then run for a long time increases the NFS and CPU load on the file server. To avoid a serious impact on other users, we will terminate those jobs, and we will recommend that the user see a consultant for some assistance in programming.
If your are not using your account for an extended period of time, we highly urge all users to logout of their account. This will keep the contents of your account safe and will prevent others from using your account in a harmful manner. If your account is on the mail system, University IT will remove all processes and logout any user who is idle for greater than one day (24 hours).
Finally, illicit processes will be terminated. This means games, either locally or over the network, or "system commands." Most commands in section 8 of the UNIX manuals fall into this category. If we suspect a security breach (e.g., your account is being logged into from a remote site, and the remote user does not appear to be you, or your account is being used to log into a remote site, and where you do not appear to exist as a bona-fide user), the processes will also be terminated.
Who shall terminate the processes? The chief responsibility for terminating processes rests on the primary system administrator for the system in question. The University IT UNIX Consultant may also terminate processes. If the primary sysadmin is not available, the backup sysadmin may also terminate processes. The individual "carrying the tricorder," the on-duty sysadmin, may also act on rogue processes, and in fact may be the one to terminate most of these processes.
What action do we take other than termination of processes? We will try to notify the owner of the process what action we have taken and why. If this individual continues to exhibit these "user process offenses," or if the offense is intentional or malicious, we will lock that user out of our systems, and require that they speak to the UNIX Consultant. The Consultant may in turn pass them on to his/her supervisor or to the system administrator involved with the problem. Ignorance can be tolerated as long as there is hope that it can be rectified. Rudeness, disregard for others on the system, and malicious behavior has a much smaller "window of tolerance."
The rules are as follows:
- No user run daemon processes.
- No user-offered network services.
-
Examples: fsp servers, httpd.
- No games.
- Long running processes (executing for more than about 30 minutes):
-
-
Long running processes should be niced.
-
Long running children of init (parent process-id 1) that have not been niced will be terminated.
-
No more than one (1) long running job will be allowed; the oldest job will be left running, and the others terminated.
-
Long running children of init that cannot produce useful output (tip, ftp, mail, mush, and so on) will be terminated.
-
Long running processes that have been idle most of their life will be terminated.
- No network games (for example, telnet foo.bar.baz.buz 2000).
-
This includes (but is not limited to) all MUD, MOO and MUSH variants, Chess, Go, and so on. IRC (Internet Relay Chat) is specifically prohibited. Contact "problem@roundtable.cif.rochester.edu" during the regular academic year for an account on roundtable.cif.rochester.edu, where games and IRC are allowed. The only exception to this ban on games is for academic courses requiring access to that facility or facilities. In the event that an instructor requires access to a local or network game as part of a full time, acredited course, she or he should contact University IT prior to using such a facility. We will be happy to assist instructors with this.
- If you are idle for greater than one day (24 Hours) on the mail system, your processes will be removed and you will be logged out.
Please note we are using the UNIX meaning of the word files, i.e., text and binary files, scripts, directories, special files and pipes, and so on.
Certain files in your home directory can and will be examined by the system administrator (see the section titled "User Rights" below) because they have an impact on the system. The files are as follows:
Files listed:
See also:
- .rhosts
-
Many sites do not allow the presence of the .rhosts file. We have chosen to allow our users to have a .rhosts file, with certain restrictions:
-
- .plan
- .project
-
These files are displayed whenever anyone fingers you. So that they are visible to other users, you should ensure that the permissions on these files are 0444 or 0644 (-r--r--r-- or -rw-r--r-- in symbolic notation). These must be plain ASCII text files, and may not be links, named pipes, etc. See also the section on user identity.
- .forward
-
It is important that you have a .forward file; we will soon being to create default forwarding files for new users on Mail, Troi, and other clients. It is especially important for you to have a .forward file if you do not normally read mail on these hosts (i.e., if you prefer to read your mail on the VAX cluster). The use of a forwarding file prevents your mail from accumulating, and helps prevents missed mail. Often the system administrators need to contact you, and email is their only route of contact.
-
- Your forward file should be world readable (octal mode 0444 or 0644), and should not be writable by anyone other than yourself. We will inform you if this is incorrect.
- We may also examine the contents of this particular file.
- Please do not include multiple addresses or invoke programs within your .forward file. One exception to this rule is that you may invoke the vacation(1) program from within your .forward file. You may also make use of features of your mail reading program; mh(1) users may choose to use the slocal filter (see mhook(1)) or the Elm filter program (see filter(1L)) to prescreen their mail, for example.
- Home directory
-
Your home directory should be world readable (octal mode 2755 or 0755). It should never be writable by anyone other than yourself; neither should any directories under your home directory, with the exception that you may choose to make certain directories under your home directory group writable (octal mode 2775, 0775, 2770, or 0770). You may choose to make your home directory readable only by yourself, but this may create problems with the system looking at your .forward, .plan, .project, or .rhosts files. If you have files you want to keep hidden, create directories under your home directory, and change their permissions to something you find acceptable; e.g., cd ~/ ; mkdir private; chmod 700 private;. Incorrect file and directory permissions can cause problems for you. We will begin warning users of improper permissions via email, and locking that user's account if there is no change within a specified time period. The email warning will be skipped if you have no .forward pointing to a useful host, and if you have not logged in in a long time.
- Special Directories and Files
-
Please use /tmp, /var/tmp, and /var/spool/ftp/pub as intended. /tmp is used primarily by programs, such as editors, for temporary work space. /var/tmp is the temporary work space for people to use (as opposed to programs). Files live longer in /var/tmp (/tmp and /var/tmp are cleaned--they have old files removed--daily). The anonymous ftp directory on troi.cc.rochester.edu, /var/spool/ftp/pub, is for anonymous ftp, and should not be used as a personal storage area. Do not place files in the anonymous ftp directory on a long term basis unless you have cleared it with the UNIX consultant. You may make programs, documents, etc. you have written available in this area (not for running, but for copying purposes), but please do not try to make our hosts archive servers for materials available elsewhere. If there is something you would like to have locally available, contact the UNIX consultant.
If we find you are running crontab(1) jobs to update the modification/access times for files in the ftp directory, we will revoke your ability to use crontab, and may lock your account. If you have a need for unusual file types (i.e., something that is not a plain file, a link, or a directory), please contact the UNIX consultant ahead of time.
- system files
-
Users are prohibited from reading, executing, or otherwise using any "system files," except when such use is part of the normal execution of an otherwise permissible command. "System files" are any files that are outside of the normal search paths, as defined in the default ".cshrc" and ".login" files. Some examples include any file in "/etc". An exception to this rule is the "/etc/passwd" file, as described below. Please note that the actual permissions of a system file do not imply that the file may be properly read. For technical reasons, system files may be world-readable. That does not mean that it is OK to read a world-readable system file.
- /etc/passwd
-
You do not really own /etc/passwd, but you do own your password; we periodically check user passwords (we have to guess them just as a computer criminal would), and will inform you via email if we can break your password. If you do not correct the situation within a specified time frame, you will be required to change your password the next time you login. The computer criminals of this world will do a much more thorough job of trying to break your password than we do, so be sure to choose a good password.
The UNIX consultant can give you guidelines for good passwords. If we find you trying to break passwords, you will lose your accounts, including any class accounts. If you should forget your password, you may have it reset. In order to do this, you must come in to the IT Center (in Rush Rhees Library) between the hours of 9:00 PM and 5:00 PM, Monday through Friday, except for University holidays. You must come in person, and you must bring your current, valid University ID card with you.
- Copyrighted files
-
Under the copyright laws of the United States and the Berne Convention, certain programs and files may have restricted distribution. Possession of any program which is not explicitly placed in the public domain without the written permission of the copyright holder is forbidden by University IT policy and by Federal law. If the consultants find any evidence that you have been using copyrighted software in ways not permitted by law, such as copying or distributing them for others, your account will be locked. Also, further action may be taken, such as: loss of accounts, University disciplinary hearings, explusion, and/or Federal criminal or civil charges.
If you have incorrect file or directory permissions, we will try to contact you via email. If it appears to us that that will not be effective (if you have not read mail in a long time on that particular host, and have no forwarding set, for example), we will lock your account to protect your files from unauthorized alterations. If you leave your files or directories with incorrect permissions after receiving a warning, we will lock your account. We may also move your .rhosts file aside if it looks as if that could cause problems.
If your .rhosts file contains unacceptable entries, we will again attempt to notify you, and may lock your account, and move your .rhosts file aside.
The usefulness of the network is based on trust. Misrepresenting yourself on the net damages that trust and the usefulness of the network. Do not misrepresent yourself. This includes, but is not restricted to:
- Incorrect "full name" fields
-
These fields are set with the chfn(1) program or its equivalent. Any entry in the full name field should accurately and correctly indicate who you are.
Setting this field to someone else's name, or setting it to indicate you are an administrator of the system is not acceptable. The system administrators will correct these inaccuracies, and will notify you of their action via email. If you persist in using unacceptable full name fields, your account will be locked.
- Forging electronic mail
-
(or otherwise falsifying your identity as the sender of an electronic message) This is completely unacceptable. Your account will be locked if you attempt this type of misrepresentation.
-
- Forging Usenet news postings.
-
(or otherwise falsifying your identity as the poster of a news article) As with forged electronic mail, this is unacceptable. Your account will be locked if you post or attempt to post a news article in which you have falsified or attempted to falsify your identity.
Forgery is a violation of the University's standards and regulations (see the reference below), and may result in disciplinary action being taken by the Judicial Officer and the All-Campus Judicial Council (ACJC), and/or other agencies, as appropriate.
Full Names, Plans, and Projects
While we strongly urge users to retain their true full name in the full name field, there is some leeway in using nicknames or short names in that field. Do not however, use a name that is not your own, do not misrepresent yourself. Your friends may know who you are, but others will not; they will have to assume you are who you say you are. Remember that this is how you present yourself to the electronic community.
Additionally, restrict your full name field to contain only alphabetic characters, with the possible exception of a period (.). Special characters (e.g., !, ~, @) can be interpreted by mailers as part of a mail address, and can cause problems for you in sending and receiving mail.
Any person who uses his or her ~/.plan or ~/.project file to threaten, harass, or intimidate another individual will be required to remove the information to maintain his or her account. Cases will also be referred to the University Administration for possible further action. Any complaints about offensive, obscene, racist, or misleading ~/.plan or ~/.project files will be referred to the University Administration for review. The user with the questionable ~/.plan or ~/.project file(s) will be allowed to maintain these files until a final decision is made by the University Administration.
Space for personal web pages is available to all users on the mail.rochester.edu and troi.cc.rochester.edu systems. All users who create personal web pages must follow all University IT and University policies, and local, state, and federal laws.
Specific Web policies include, but are not limited to:
- Do not use web pages to promote commercial or non-profit activities that are not approved by the University.
- Do not use web pages as a medium to harass, threaten, or transmit libelous information regarding another person.
- Do not use web pages as a medium to transmit or store copyrighted or licensed material.
- Do not attempt to run CGI scripts or any other programs via a personal web page.
- Do not use web pages to circumvent security measures on any computer system.
- Do not attempt to mis-represent yourself or anyone else on your web page.
- Do not attempt to modify another person's web page.
- Do not create web pages that abuse system resources.
- Any complaints regarding web pages that contain obscene, racist, misleading, or offensive material will be referred to the Assistant Dean of Students Office. The user with these questionable web pages will be allowed to maintain them until a final decision is made by University Administration.
As we have stated in this document, there are certain files we will examine. The system administrator has the ability to examine any file on the system; we normally will examine (including reading the contents of) the following files: .rhosts, .forward, and will verify the permissions of your home directory and its sub-directories.
In order to maintain a safe, reliable system for all users, University IT reserves the right to examine any files on our systems if we determine there maybe a problem.
For example:
- If we see a program of yours running out of control, we may attempt to read the source code to determine if it is indeed out of control and using up your computing funds. We usually attempt to contact you by email or phone as the first step if we have such a problem.
- If we suspect a system security problem (unauthorized access of your account or from your account, abusive mail or intrusive programs coming from your account, etc.), we may examine the files/programs suspected of causing the problem. An example of this is a program that sends 'humorous' messages to the screens of randomly selected users. We may need to examine your .login or .logout or .cshrc (or .bashrc, or .profile, or any shell startup/shutdown file).
- We will not read your system mailbox (in /var/mail/userid), or your mailbox under your home directory (~/mbox, or ~/Mail), although we will attempt to notify you if either mail folder directories are writable by anyone other than yourself, or if mail files are world readable or writable.
- We will schedule any downtime and announce the downtime one to three days in advance (depending on the particular host) so that you can plan around downtime. This does not apply to emergency downtime or crashes, of course. Please refer to the System Downtime Policy for more details.
Users must understand that if they choose to store private information on a public system like Mail or Troi, there is always the possibility that someone else maybe able to read that information. If the permissions are not set properly on a file, it could be accessible by others. Also, if someone gains access to your account, they could also have access to your files.
College Undergraduates, ESM Graduate and Undergraduate Students
- If you are graduating in May of the academic year, your e-mail account on Mail will remain open until October 1st of that year. You will receive a notice approximately 30 days prior to your account closing. This will allow you ample time to find new e-mail services and transfer any files you have on Mail to that new service. After October 1st, your e-mail account will be removed from Mail Users should download any files they need and notify people they are in correspondence with that they should not send e-mail to their Mail address after October 1st.
- After October 1st, University IT cannot provide any automatic mail forwarding services or retrieve any of the files in your e-mail account for you. After your account is expired on October 1st, any mail that it sent to your mail e-mail address will be undeliverable and will bounce back to the sender the message. We cannot continue to allow mail to to be forwarded from mail to your new account because we do not have the system resources and overhead.
- For those students who graduate at other times, are withdrawn, change their status to a faculty, staff member, or switch to another school outside the College or ESM, you will be sent a notice 30 days prior to your account closing. University IT does not grant any account privileges for those students who are withdrawn; however, students on inactive status may maintain their accounts in order to keep in contact with the University.
Faculty, Staff, College Graduate Students, other Departmental Accounts, and other Individual Accounts.
- Most departmental sponsored accounts are closed around the July 1st time period. The closure of a Departmental sponsored e-mail account soley depends on when your department notifies University IT that they no longer wish to sponsor you for an account. If you are concerned about when your account is going to close, please check with your department administrator or supervisor to see when they will put in the request.
- If you are paying for an individual account, you will be notified each year when your account renewal is due.
- If you are a graduate student in the College, a faculty member, or a staff member, and your account on an University IT UNIX system is expired or closed, University IT will allow you to have your e-mail automatically forwarded from your closed account to a new account for a three month time period after the account has been closed. If you do not setup a mail forwarding file before your account closes, you will need to fill out a Closed Account Request Form and send it to University IT. University IT will then setup mail forwarding for you.
- During the three month time period after your account is closed, University IT will also allow you to retrieve files or mail you need from your account. You will need to complete an University IT Closed Account Request Form and send it to University IT.
- If your account on an University IT UNIX system has been closed for greater than three months, we cannot setup mail forwarding or retrieve files for any users.
If you plan to access your Mail or Troi account from
- outside the Greater Rochester Area and/or
- outside the U. of Rochester Network (rochester.edu)
University IT requires that you run the command:
away
as soon as possible from your prompt and answer the questions presented to you. You will be asked to answer questions regarding the location you are logging in from, the name of the computer you are logging in from, and other information.
The away program will also request that you provide University IT with a 'pass phrase' that is different from your password. This 'pass phrase' can be used to assist you if you lose access to your account while you are away from the Rochester area. For example, if you forget your password, or your account becomes unavailable to you, you may still be able to gain access to your account even if you cannot come to the IT Center in-person.
If you cannot answer every question the away program asks, please try to provide us with as much information as you can. You can run the away command as many times as you need to as long as the information you provide us is correct and up to date.
All information you provide in the away program is kept completely confidential and is only looked at by University IT Systems Administrators and/or UNIX Consultants. The primary reason we require users to run the away program is for the protection of your account. We want to make sure all accounts are secure. If you do not use away promptly, your account may be made unavailable to you as a security precaution.
We will make our best effort to provide you with reliable service and access to your account. However, we cannot guarantee that your account will be accessable at all times.
In particular, it may be necessary to take one or more of our systems down for maintenance. Our regularly scheduled maintenance windows are:
- between the hours of 6:00 AM and 8:00 AM on weekdays
- between the hours of 6:00 AM and 12:00 PM on weekends and University holidays
If it is necessary to take a system down for maintenance during these times, a notice will be posted in the "Message of the Day" seen at login. The notice will generally be posted at least three days in advance. At times, it may be necessary to schedule extended downtime to perform major repairs or upgrades. When this is necessary, a notice will be posted in the "Message of the Day" seen at login, and additional information may be posted to the "msgs" system message facility. The notice will generally be posted at least three days in advance.
If the system appears to be down outside of the scheduled maintenance times, please notify University IT by calling 585-275-2000.
It may be necessary to take a system down for emergency maintenance at any time. We will do everything we can to avoid inconveniencing our users, but in some circumstances the inconvenience cannot be avoided. Please understand that we cannot and do not make any guarantees about your ability to access or use our systems at any given time. We recommend that you schedule your projects accordingly, so that an unexpected system malfunction will not cause a personal emergency. If you have a "mission critical" application, please contact University IT at 585-275-2000 for assistance in creating a "disaster plan."
University IT may need to make their services unavailable to you if we are aware that you violated a computing policy in some other area of the University. Users of our systems who abuse their University computing privileges will not be granted any privileges on University IT systems until the situation is resolved where the policy infraction incurred.
The following is a list of areas where University IT and other University departments will work together in case of security problems on Mail, Troi, and other systems.
- In the event that a users account is compromised on Troi, Mail, or another system, a collaborative lock will be made on the other systems where the user has an account to prevent any further security breach.
- In the event of a system compromise (or an attempted system compromise) on either Troi, Mail, or another other system, where account security is involved, collaborative locks will be made accordingly on all systems.
- Any other areas where collaborative locks are necessary will be handled on a case-by-case basis.
University IT will do our best to notify users of any problems on the systems in a timely fashion. However, in some cases we may be required to make our systems unavailable without giving users prior notification.
In the event of major system problems due to either hardware failures, security breaches, or other problems, University IT will have signs posted in Taylor Hall and the IT Center notifying users what the problems are, an approximate time when the affected systems will be available, and what actions (if necessary) need to be taken by you. We suggest that if you notice any problems with University IT systems, that you either notify us promptly by calling x5-2000 during the week.
If the system problems occur over a weekend time period, University IT will try to have staff available to make sure users can find out information regarding the system problems and will try to have the systems available in a timely fashion. If the nature of the problem requires users to take an action, we will have signs posted on where to go and what you need to do.
If any Mail user attempts to email a message or receive a email message that is greater than 20 Megabytes in size that message will not be accepted by Mail and the message will bounce back to the sender with an error saying the message is too large.
The number of messages a Mail user receives is not affected by this. Mail users will still receive any number of mail messages they currently get, but the size of each individual mail message must be less than 20 Megabytes in size.
If you do wish to transfer large messages to other users, we suggest you use FTP (File Transfer Protocol) or a web page to do this. E-mail is not an appropriate medium for transferring large files.
Using POP and IMAP mail clients like Eudora, Netscape, Microsoft Internet Mail, etc. to access mail from any University IT system is only allowed from inside the rochester.edu network. This includes anywhere on campus where these mail clients are installed and using the University VPN (Virtual Private Network) Service.
Using POP/IMAP mail clients to access mail from any University IT system from another Internet Service Provider or network is not allowed and is an unacceptable security risk. The POP/IMAP protocols have many known exploits that allow users to gain unauthorized access to systems and University IT cannot take the risk to allow people from outside the rochester.edu network to gain unauthorized access to our systems using these protocols.
Users who wish to access their e-mail from another network or Internet Service Provider can either SSH directly into the system and read their mail on the server, or they can also forward their mail to another e-mail account they have with their provider.
We strongly discourage the use of the feature in mail programs such as Eudora or Netscape Communicator that automatically checks for incoming mail. Users should manually check for incoming mail whenever they feel it is necessary.
Users that absolutely must use the auto-check feature must make sure that they are not checking their mail more than once every 15 minutes. If a user checks their mail more than this, their account may be locked and all incoming mail will be bounced back to the sender.
Questions or corrections? problem@mail.rochester.edu
|
