Locking settings
How the settings lock protects rules, profiles and settings on a shared Mac, and what changes when the organization turns rule editing off.
Outbound has two separate ways to stop a user from changing things. The settings lock is a local lock for a shared Mac or a child’s account: an administrator turns it on in Settings and only an administrator can unlock it. An organisation can also force it on with SettingsLocked, and then it cannot be turned off on the Mac. Organisation enforcement comes from MDM: when UsersMayEditRules is forced false, ordinary users cannot edit rules, though a root process overrides that one. See Managed preferences.
Turning the lock on
Section titled “Turning the lock on”In Settings › Security, under “Administrator Lock”:
- Turn On Lock: locks the protected areas immediately.
- Turn Off Lock: appears after you have unlocked; it removes the lock entirely.
- Lock Now: locks again after an unlock, without turning the lock off.
The lock itself is persisted in the settings file, so it survives restarts and updates. See The rules file format for where that lives.
The three protections
Section titled “The three protections”| Setting | Default | What it protects |
|---|---|---|
| Protect rule editing | On | Creating, editing, removing and approving rules, in the Rules pane and over outboundctl. |
| Protect profile switching | On | Switching profiles, including automatic switching by network. |
| Protect these settings | On | The other Settings pages. |
All three default to on, so turning the lock on protects everything until you narrow it. The toggles are editable only while the lock is off: an administrator decides what the lock covers, and a user cannot reach those switches to loosen it.
The Security page stays usable while locked: it holds the “Unlock…” button, so a user can still call an administrator without restarting the app.
Unlocking
Section titled “Unlocking”Unlocking asks for an administrator’s name and password: Outbound requests the macOS system.preferences.admin authorization right with the prompt “Unlock Outbound settings to change network protection.”
Two rules govern how long an unlock lasts:
- The unlock is for the current session of the app only. The persisted lock stays enabled: quitting Outbound or restarting the Mac locks the settings again.
- If the settings were locked while authentication was in progress, the unlock is refused and the lock stays.
What each protection blocks
Section titled “What each protection blocks”- Rule editing: adding, editing, removing and approving rules in the Rules pane, and the same changes over
outboundctl. Alerts still appear and can be answered, but the scope pickers are not shown: the alert says “Your organization does not allow saving rules, so this answer applies to this connection only.” - Profile switching: the Profile menu in the Firewall menu, the menu bar panel and the Profiles page. A network joining does not switch profiles either while this is on.
- Settings editing: the other Settings pages. Their controls are disabled while the lock is on; the Security page stays usable so the lock can be released.
Outbound and the command line
Section titled “Outbound and the command line”The Command Line section on the same page has an outboundctl changes picker: Allow tightening, Ask every time or Off. It controls the command line independently of the lock, and an organisation can force it with CLIChanges. Off keeps outboundctl read-only: status, history and explain still work, everything that writes is refused with “outboundctl changes are disabled in Outbound Settings. Change Command Line access in the app.” Both this toggle and the protections are checked by every changing command:
| Situation | Exit status | Message |
|---|---|---|
| outboundctl changes set to Off | 77 | “outboundctl changes are disabled in Outbound Settings. Change Command Line access in the app.” |
| Settings locked and the command touches a protected area | 77 | “Settings are locked. Unlock them with an administrator account to make this change.” |
UsersMayEditRules forced false and the command is not run as root |
77 | “changes are not allowed: your organization has turned off editing of rules (UsersMayEditRules). Run as root to override.” |
Root (sudo, an MDM post-install script) overrides the organization’s rule-editing lock but cannot bypass the settings lock or the outboundctl toggle.
What a managed Mac user sees
Section titled “What a managed Mac user sees”When the organization forces UsersMayEditRules false:
- Rule editing controls are disabled across the app: adding, editing, removing, approving rules and subscriptions.
- A “Managed by your organization” note with a lock icon appears where editing is gated, instead of the controls doing nothing silently.
- The mode picker is disabled separately when the organization forces
Mode, with “Your organization sets the mode”. - Managed rules are listed under the Organization scope in the Rules pane.
Organisation enforcement and the settings lock are independent: a Mac can have UsersMayEditRules forced false while the settings lock is off, or a locked Mac where the organization leaves editing open. Whichever is stricter for a given area applies.