User management and access control
Nanite Systems recreational units support comprehensive user management over the teletype interface or the local menu. There are five distinct levels of user: unauthorized users (the public), group members, authorized (regular) users, managers, and owners. (Later versions may add or remove ranks.)

Blacklisting and whitelisting guests


If an unauthorized user attempts to access the system, then by default, the unit will be given a short interval of time in which to consent or object to the access attempt. Individuals managed this way are called guests. When the access attempt is first made, the unit is given the following options:
  • permit: The guest is added to the permanent whitelist and may continue to use the unit at any time without further prompts.
  • ban: The guest is added to the permanent blacklist. Future attempts to use the unit will be ignored without prompts.
  • trust: The guest is added to the temporary whitelist. Permission will expire after a period of inactivity. (Default: 10 min)
  • refuse: The guest is added to the temporary blacklist. Continued attempts to use the system will be rejected. After a period of inactivity, this restriction will expire. (Default: 10 min)
  • permit once: The single requested action, such as a menu prompt, device connection, or command, will be allowed. Subsequent access attempts will continue to prompt the unit for permission.
  • ignore: The single requested action, such as a menu prompt, device connection, or command, will be disallowed. Subsequent access attempts will continue to prompt the unit for permission.
If access by the public is disallowed (see sections on local and remote access control, below) then the guest system is bypassed entirely and no prompts are generated, even for whitelisted guests. Prompts can be disabled entirely with the consent policy setting, found under manage > policies > access > consent. Disabling consent while public access is enabled returns the unit to the behavior in previous releases, which is automatic acceptance of all user accesses.

If the prompt times out (default: 10 seconds) then the guest is automatically added to the temporary whitelist, permitting access in a manner similar to previous versions of the system.

To manage the stored white and black lists for guests, see the command guests.

Adding a new user


Adding a new user is accomplished through the manage > users > add voice prompt menu. The user must be physically present to be added. Only managers and owners may access the manage menu, and therefore add new users.

Creating a manager


Managers are users trusted by the unit’s owner(s) to ensure that it is properly configured and that its list of authorized users is accurate. They may perform any operation on the unit other than creating other managers, transferring the unit’s ownership, or resetting the submission security management module. (See Understanding the system software architecture.) To set an existing user to the manager role, select the user’s name from the manage > users menu and then press promote.  To demote a manager back to regular user, press the demote button under that manager's name.

Owner vs. manager


Owners cannot be removed or demoted from the system by managers. Both otherwise have full access to configuration settings. Owners are treated separately by access options (both remote and local access options have 'owner-only' mode), and additionally the unit is automatically required to accept a teleport invitation from an owner if one is offered.

Removing a user


To remove a user, select the user’s name from the manage > users menu and then press remove. A manager may only remove regular users and himself or herself. If the owner is removed, the unit will automatically take on self-ownership as if it were newly manufactured.

Transferring ownership


To transfer ownership to another person: add that person to the unit’s user list, select his or her name from the manage > users menu, and then choose submit. They will be promoted to owner, and you (the previous owner) will be automatically set to manager status.

Multiple owners


The unit can have multiple owners simultaneously.  To promote someone to owner from manager, select his or her name from the manage > users menu, and then choose promote.  Current owners will remain owners, and the manager will be promoted to owner status.
All owners will have the same rights and access a single owner would.  Note: Any owner can demote any other owner with the demote button. They can also click the submit button which will demote all current owners to managers, and promote the user in question to owner.

Abandoned units


In the event a unit is abandoned by its primary owner, it can be sanitized by clearing the NVRAM and wiping the security manager’s active user table. This is accomplished with the keychain reset command, which must be executed by the unit itself or its current owner.

Saving and restoring user lists


The commands keychain save and keychain restore record and recover the list of users and their ranks to and from NVRAM, respectively. Information for up to 30 users may be saved this way. If more than 30 users are known to the system and an attempt is made to save the users to NVRAM, a warning message will be emitted and the list will be truncated to the first thirty users, ordered first by descending rank and then ascending order of addition.

Access



Local access control


Local access determines who may use the TTY menu and the touchscreen, among other things. It comes in four levels: public (anyone), group (all authorized users + the unit’s group), users (only authorized users), and private (owners and managers only.) This can be configured from the manage > policies > access menu, or remotely with the access local <level> command, in which case ‘public’ and ‘private’ access are referred to as the levels ‘on’ and ‘off’.

Other perks of local access, besides menu usage, include local command access with /1, automatic trust through the RLV relay and navigation nodes, and automatic trust for communicating with foreign peripherals such as powered doors or maintenance tables. /1 commands are limited to chat range (20 m) and local menu access is limited to 10 m, but RLV devices, navigation nodes, and foreign peripherals may operate at any distance.

Remote access control


This is analogous to local access (above), and affects who may use remote console access (see [a href="/?id=224"]Remote access[/a]) to control the unit. The console command for managing remote access is: access local <level>

Note that remote console access can also include menus, but these are tracked separately and do not interfere with usage of the touch screen or local TTY menu session.

Self access control


Self access allows the unit to interact with its systems. When self access is disabled, the unit is unable to use @ commands, remote access, or local access, even if it is self-owned. Self access can be controlled through either the self option on the manage > policies > access menu, or the access self <state> command, where <state> is ‘on’ or ‘off’.
Note: In the event that self access is unintentionally disabled, the command @safeword will allow the unit to regain basic control over its systems. This command can only be used by the unit itself.

Locking


PIN-based locking prevents local access by all users (including the owner) until the correct PIN is entered on the touchscreen or over the TTY menu interface. The PIN can be set in the manage > policies > access > set new PIN menu. To lock the unit, press lock on the manage screen, or execute the lock command.

Cancelling PIN changes: Press the clear button to abort setting a new PIN.

Default value: The default PIN is an empty string. If you accidentally lock the unit, simply press enter.

Autolock: The unit can be configured to automatically lock itself after a certain period of inactivity, using either the autolock item on the manage > policies > access menu, or the autolock command. The autolock command can also be used to set the timeout interval, which defaults to 30 seconds.

User role summary


levelnameabilities
guestscan access non-management controls if public access is enabled and consent is granted by the unit
0regular userscan access non-management controls if user access is enabled, consent not required; can exchange IMs if radio policy is set to 'users only'
0group usersas above, but only if group access is enabled; not included in 'users only' radio policy
1managercan access all controls if user access is enabled, but cannot affect owner accounts; can exchange IMs if radio policy is set to 'users only'
2ownerfull control, teleport requests are automatically granted; can exchange IMs if radio policy is set to 'users only' or 'owners only', receive distress beacon messages, receive notices of keychain resets and safewording