Users and Access

6.0 User Management

Every caller who registers gets a record in the Synchronet user database (data/user, historically user.dat). Sysops create, inspect, modify, and delete those records with online and offline tools.

Access identity on each record includes:

• Security level (0–99; 90–99 operators)
• Four flag sets (A–Z each)
• Exemptions and Restrictions (A–Z, predefined meanings)
• Optional expiration date
• Credits and minutes (time bank)
• Profile fields (alias, real name, location, netmail, etc.)
• Activity stats (logons, posts, UL/DL)

New accounts pick up defaults from SCFG → System → New User Values.

Wiki: https://wiki.synchro.net/access:index · https://wiki.synchro.net/access:user_editor

6.1 In-BBS User Editor (;UEDIT)

The in-BBS user editor is a terminal single-screen editor for the current user record. It is not the same program as standalone uedit, Win32 useredit.exe, or gtkuseredit.

Invoking

Screen contents

Shows alias, real name, address, host/IP, netmail, first/last on, time, logons, posts, UL/DL, credits, minutes, level, flags, exemptions, restrictions, then a one-key command prompt (User edit (?=Menu)).

Indicators called out in the wiki include attached comment/message files and other status markers — press ? inside the editor for the command menu for your build.

Remote limits

Remote sysops cannot escalate past their own level/flags/exemptions or edit higher-level users (see 5.1).

Wiki: https://wiki.synchro.net/access:user_editor

6.2 uedit (standalone)

uedit is a console/UIFC utility for creating, editing, or listing users outside a caller session — useful when the Terminal Server is down or when working over SSH on the host.

• Run from exec with access to the BBS data/ctrl tree.
• Provides New User and edit flows in a full-screen text UI.
• Prefer this (or GUI useredit on Windows) for local admin; prefer ;UEDIT when already in a moderated session reviewing a specific caller.

Wiki: https://wiki.synchro.net/util:uedit

6.3 Bulk User Editor (allusers)

ALLUSERS applies security modifications to many users in one command line — for example strip an exemption, add a restriction, or bump/lower levels matching an ARS-style requirement.

Syntax (conceptual)

allusers /path/to/data/user -require /modify

• First argument: directory containing the user database (or . if current).
• Optional -require: limit which users match (security requirement).
• /modify style arguments: add/remove flags, exemptions, restrictions, set level, etc.

Always run against a backup first on production boards. One wrong requirement string can modify the entire userbase. See the utility’s own help output for the exact modify switches on your version.

Wiki: https://wiki.synchro.net/util:allusers

7.0 Access Control

Access control is broader than user records. Synchronet combines:

1. Host filtering — filter files restricting IPs/hosts or words in user-generated content
2. New user gates — closed to new users; New User Password (NUP) in SCFG
3. Per-user security fields — level, flags, exemptions, restrictions, expiration, credits, minutes
4. ARS on almost every feature (subs, file dirs, doors, menus, operator requirements)

Host filtering & new users

• Filter files (see config filter-file docs linked from Access Control) can block ranges or trash content containing banned words.
• SCFG → System → Toggle Options → Closed To New Users
• SCFG → System → New User Password for semi-secret registration

New User Values

SCFG → System → New User Values sets the template for brand-new accounts (default level often 50 in examples, flag sets, exemptions, restrictions, expiration days, credits, minutes, default editor, command shell, download protocol, etc.). Tune this before opening registration publicly.

Wiki: https://wiki.synchro.net/access:index

7.1 Access Requirements (ARS)

Access Requirement Strings (ARS) state who may use an area or function. You will see them labeled ARS or “Requirements” throughout SCFG.

Default allow vs default deny

• Most requirements are default allow: blank string → everyone matches.
• Some are default deny: blank → nobody matches. Examples called out on the wiki:
• Operator Requirements
• Exemption Requirements
• Moderated Posting User

Always know which kind you are editing before clearing a string.

SCFG Requirements dialog

SCFG offers an interactive builder: edit the raw string, clear requirements, or append common constraints (terminal type, user type, level, flag, age, gender, PC ratio, credits, UL/DL ratios, time of day, day of week, user number, time remaining, …).

Wiki: https://wiki.synchro.net/access:requirements

7.2 Keywords and symbols

ARS has a compact keyword/symbol language (level comparisons, flag tests, NOT, OR, parentheses, time keywords, etc.). The full keyword tables live on the Access Requirements wiki page — they are long and version-sensitive.

Teaching summary (verify exact tokens on the wiki before production use):

• Level tests (equality / inequality / ranges depending on documented syntax)
• Flag set tests (FLAG / set number / letter — per wiki syntax)
• User number, age, sex/gender keywords
• Terminal capability keywords (ANSI, RIP, PETSCII, … as documented)
• Time-of-day and day-of-week gates
• Boolean connectors and grouping symbols for compound expressions

Wiki: https://wiki.synchro.net/access:requirements

7.3 General usage examples

Typical real-world patterns (illustrative of kinds of policies — copy exact syntax from the wiki examples section):

• Require minimum level to enter a file library
• Require a flag for “donor” areas
• Restrict a door to evening hours
• Allow a sub only to users with enough posts or credits
• Limit an operator-only external to sysop level / operator ARS

Start from the SCFG dialog so the string is built correctly, then learn the raw syntax for nested cases.

Wiki: https://wiki.synchro.net/access:requirements

7.4 Nesting expressions

ARS supports nested boolean logic so you can express “level ≥ 60 or (flag X and not restricted Y)” style policies. Nesting is where typos hurt: a misplaced parenthesis can open an area to everyone (default allow) or close it to everyone.

Recommendations:

• Build incrementally; test with a throwaway user account at known level/flags.
• Prefer clear flag design over deep nests when possible.
• Document non-obvious ARS strings in a sysop note or local wiki.

Wiki: https://wiki.synchro.net/access:requirements

7.5 Nested logic examples

The Access Requirements page includes nested logic examples — use those as the canonical copy-paste references. When a page section is unclear, experiment on a non-public sub first.

Related: moderated posting ARS (default deny) ties into message-base moderation (Sysop Bible / https://wiki.synchro.net/howto:moderation).

Wiki: https://wiki.synchro.net/access:requirements · https://wiki.synchro.net/howto:moderation

Access design checklist

• [ ] New User Values match the community you want
• [ ] Level 90+ reserved for real operators only
• [ ] Flags documented (what Flag1-A means on your board)
• [ ] Dangerous doors wrapped in tight ARS
• [ ] DNS/host filters enabled if under scan pressure
• [ ] Backup before allusers

Wiki: https://wiki.synchro.net/access:index · https://wiki.synchro.net/access:requirements · https://wiki.synchro.net/access:user_editor · https://wiki.synchro.net/util:uedit · https://wiki.synchro.net/util:allusers