SCCS Policy Board Document

SCCS Policy Document

Major decisions of the SCCS policy board. Note that all dates are in the form yy.mm.dd

Item 1: Policy board operation

Policy board meetings will have a loose parliamentary structure; the SCCS president will normally serve as speaker. The board may appoint a different speaker for a meeting or a series of meetings. Our goal is to write a single, unified policy document. We will publicly archive all meeting minutes. All votes and other policy board actions will be recorded in a diary.[95.9.28] [addendum 95.10.31: that diary is simply a log of the policy mailing list; minutes need not report a roll call vote, only the final result]

The new SCCS constitution allows the sysadmins a veto on any matter other than sysadmin removal. In respect of this, either of the sysadmins on the board may request that we delay any action until the sysadmins have a chance to veto it. [95.9.28]

Any policy board member can raise an issue to the policy board list (policy@sccs.swarthmore.edu) requesting quick attention. The next twenty four hours (more or less) can be used for discussion, and any member can request that the matter be put off until the next physical meeting. If no one requests the delay, the president will issue a call for votes. Votes will be mailed to the president who will then summarize the votes (with attribution) to the policy list. If the matter is particularly pressing, the president can announce a result based on agreement of three members even if not all five have voted.[95.9.28]

Abstentions (and tie voting):

Normally actions take three votes to carry. With abstentions, only a simple majority is required. [95.10.31; temporary, pending reference to parliamentary procedure]

If a vote ties as a result of abstentions, we ask, but do not demand, that any members who abstained participate at their discretion and vote again. If we're still tied, we send a message to all officers and sysadmins NOT on the poliy board stating the different opinions on the board and asking for a) comments, and b) how they would vote on the same matter. In light of their input, we vote again. And if we remain tied, we accept the vote of the officers and sysadmins not an the board, allowing each one vote. [all adopted 95.9.28]

The policy board may appoint a subcommittee of itself to handle reviews of current sysadmins. [95.10.10] All discussion of sysadmin candidates will be stricken from staff and policy board diaries. [95.10.31]

Item 2: Usernames

We will allow usernames that consist of:

cc usernames

first, middle, or last names or any combination thereof

initials

a combination of name and initials (ie. Evan Dorn could be "evand", but not "evdo" or "evando".

nicknames; the common (samuel->sam, alexandre->sasha) and widely used uncommon nicknames

[accepted 95.10.5]

Added to this are

truncations of the last name

first initial and truncations of last name

usernames must be at least three letters long, except if someone is using their two letter last name as their username

this username policy applies only to new accounts and username changes from now on, all existing users can keep their username

Additionally, we allow whimsical nicknames in the middle of the real name (GECOS) field. The sysadmins may reject any such nicknames they find offensive, but the user may appeal to the policy board.
[E-mail vote 95.10.10]
In the above phrase, "widely used uncommon nicknames", we define "widely used" to mean recognized or used by the swarthmore community at large. An example of this is if professors recognize the student by this name.

We would like to recognize that particular existant usernames are not consistent with this policy and are considered "grandfathered". We cannot retroactively apply this policy clarification to existant usernames. [adopted 99.02.08]

Item 3: Disk usage

(to be removed) Non-sysadmins are limited to 10MB of files. All files including web pages and mail spool are included in this limit [95.10.10]. Non-sysadmins are limited to 20MB of files in their home directories. A "soft quota" of 20MB is also enforced for people's web-docs directories. Users with legitimate web-docs needs larger than 20MB may appeal to the SCCS Policy Board for an increase in disk quota size.
[adopted 98.12.01]

To enforce limits, sysadmins are instructed to:

automatically mail people with home directories over the limit from a script run weekly.

the third consecutive week a directory is over the limit, that account is frozen to be reenabled only upon personal application to any sysadmin.

if the account is still over limit at the next running of the script, the account is frozen once again (same procedure for reactivating it)

at the third running, the account is frozen and the policy board is notified. At that point, the policy board will review the fate of that account.

[adopted 95.10.10]
[updated 98.12.01]

Item 4: Account Guidelines

SCCS Users are expected to comply to the following guidelines. SCCS Users will be informed of these guidelines through an e-mail message sent during new account creation.

Users are expected to comply to the Swarthmore College Computing Guidelines dictated in the Student Handbook.

To use the system in good faith. Users are encouraged to experiment, but must not try to override existing security.

Respect other users and their data. For example, users should not browse through other users' directories unless they have been given explicit permission to do so. In other words, /home/username directories are private.

Accounts and passwords to accounts must not be shared. Accounts are for the exclusive use of the account holder. Permitting more than one user on each account is an unacceptable security risk for the whole system. Users must take reasonable precautions to safeguard their password. If unauthorized users gain access to the system through a users account, that user will be held responsible.

Users may not make excessive or inappropriate demands on our resources. Examples of exessive or inappropriate demands include but are not limited to mail bombing, spamming, processor hogging, disk space hogging.

Sysadmins will act in an honest and responsible manner. Due to their limited resources, they can not guarantee data privacy, integrity, or anything else.

Violations of these usage guidelines may result in punishments up to and including the cessation of account priviledges.

Use of the SCCS implies understanding of and consent to the above terms.

[added 98.12.1]

Item 5: Guideline Enforcement

Given reasonable suspicion that a user is violating the usage guidelines dictated above, a sysadmin at his/her discretion may take any necessary actions to enforce these guidelines and ensure the safety and securty of the system.
These actions include anything up-to and including the immediate freezing of the suspected violator's account.
Once these measures have been taken, it is the task of the policy board to adjuciate the matter and decide upon a reasonable disciplinary action.
The policy board must meet within a week of the incident to decide upon a course of action. This decision must subsequently be e-mailed to all parties involved, including the SCCS staff.
The suggested course of action for guideline violations is to place the user on disciplinary "probation". The users account may be un-frozen subsequent to the user appearing in front of the policy board to explain themselves and recieve judgement.
More extreme measures including the immediate cessation of account priviledges and subsequent removal of account information may be taken if dictated by the circumstances.
The user may appeal the above decision at the next meeting of the policy board.

[added 98.12.1]

Item 6: disabling accounts

We recognize two pricipal levels of account "freezes":

** Level 1: logins and ftp to the account are disabled

** Level 2: all services including login, ftp, web, and anon ftp (if available) are disabled. Mail is normally still accepted, but may be disabled given cause (ie. a user being mailbombed, or a user trying to use mail processing to circumvent other account disablign measures)

Methods of disabling accounts:

Disabled accounts should have the password field in /etc/passwd "starred out" to prevent use of the account via ftp. [95.10.10]

Web pages should be locked as inobtrusively as possible. If practical, server config fiels should be changed. Otherwise, the user's web-docs (or similar) directory should be moved to, say, web-docs.frozen, rather than having its permission changed.[95.10.31]