Skip to content

Cannot SAVECONF when the seccomp sandbox is enabled

Summary

Issuing a SAVECONF to tor when the seccomp sandbox is enabled fails.

Steps to reproduce:

  1. Start tor with Sandbox 1 set and controller access
  2. Send SAVECONF via the controller

What is the current bug behavior?

Sending a SAVECONF currently results in this answer:

250 OK
551 Unable to write configuration to disk.
250 closing connection

and tor logs:

Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [notice] Renaming old configuration file to "/etc/tor/torrc.orig.1"
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [warn] Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": Operation not permitted

and unsurprisingly the current tor configuration was not saved to torrc.

What is the expected behavior?

SAVECONF should work even when the seccomp sandbox is enabled.

Environment

I tried with both tor 0.4.4.6 and 0.4.5.6 on an Debian Buster, using your .deb:s.

Relevant logs and/or screenshots

Except the log I posted above, sometimes I saw this instead but I don't know why it's different:

Mar 05 12:06:00.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.tmp (on Tor 0.4.4.6 )
Mar 05 12:06:00.000 [warn] Couldn't open "/etc/tor/torrc.tmp" (/etc/tor/torrc) for writing: Operation not permitted
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information