security
ARES System Manual: security Module

security yes|no|trust|block <key>: Respond to a consent prompt. (Unit only.)

security user|manager|owner <key>: Add or update a user.
security guest|ban <key> [<time>]: Add a ban or guest, either permanently or for <time> seconds.
security forget <key>: Remove a user, guest, or ban.

security reset|runaway: Clear the unit's user list. Existing owners will be notified.
security audit: Check for missing name entries and assign self-ownership if the unit has no owner.

security rules: List all security rules. See rules for more detail.
security <rule> 0-6: Modify a security rule. (See below.)

The new value for a security rule can be specified with a mnemonic instead of a number. The rule values are:

0 (nobody): no one may do this
1 (all): consent is not required to do this
2 (consent): guests and all users may do this
3 (user): all users may do this
4 (manager): managers and owners may do this
5 (owner): only owners may do this
6 (self): only the unit may do this (no rank required)

ARES has no consent timeout. Requests stay in the system until the unit answers them.


User Ranks

ARES has the same privilege levels as Companion: bans, the public, guests, users, managers, and owners. For the most part, the privileges afforded to these roles are defined by customizable rules.

Guests can be admitted by the unit itself, typically in response to access attempts. Higher ranks can only be assigned by users with sufficient permissions.

By default:

- No consent is required to trigger arousal, but anyone the unit has banned from consent will not be able to arouse the unit.
- The unit may consent to guests who wish to chat through the unit, access its menus, modify its voice or persona settings, or run local commands.
- User rank is required for running commands remotely, and users may remove themselves from the unit's user list.
- Manager rank is required to delete files, add users, change identity settings, use the settings or access control menus, or force the unit to teleport from another sim. Managers may also create more managers.
- Owner rank is required to remove managers once created, and to add new owners.
- Whatever the unit's rank, even if completely banned from its own system, it may trigger the 'safeword' program to break RLV restraints, initiate a run away from all users, and demote owners.


Primary Owner

Although ARES fully supports multiple owners, some tasks and protocols require that a single individual be nominated as the unit's owner. In these cases the unit's 'primary' or 'identified' owner is used.

Typical examples of situations where a single owner identifier is required include: the public bus ping message, performing maintenance tasks on a diagnostic bed, and resetting the user list.

The primary owner is normally the owner that was configured first, although if this user is demoted or removed, one will be selected arbitrarily from the remaining owners (whoever has the largest UUID).

The current primary owner is indicated by the id.owner database entry, and may be changed at any time using the db utility. If it is missing, devices and programs that rely on it should assume the unit is self-owned.


Policies

This is a catch-all term for miscellaneous restrictions that can be applied to the unit. Typically these are things unrelated to power consumption, but are popular among RLV enthusiasts. See policy for more information.


Tips

To stop guests from accessing the system entirely, ensure all rules require 3 or higher.

To make the system public access, switch all values to 1.

The ban list always takes priority, except for rules with the value 6. You can deny self-access to the unit by adding it to the ban list. This is called self-banning.

If the unit is self-banned, then the security runaway command will be inaccessible. Use the hardcoded shortcut runaway instead.

See rules for more information about each rule and recommended values for them.

In Companion, the security system was spread between submission and various other modules.