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
(firstname.lastname@example.org) 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
- 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
Added to this are
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.
- truncations of the last name
- first initial and truncations of last name
[E-mail vote 95.10.10]
- 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
[E-mail vote completed 95.10.26]
[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.
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
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
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
safeguard their password. If unauthorized users
gain access to the system through a users account, that user will be held
- 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
- 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
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
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
Item 6: disabling accounts
We recognize two pricipal levels of account "freezes":
Methods of disabling accounts:
- ** 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)
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]