Sandbox: bad syscall attempt (syscall getrlimit) after "New control connection opened"
Tor crashes with stack trace when sandbox enabled and controller (arm) connects. This is a regression at some point between c21377e7bcc70d2a456409225d8b2d91990a14cd
(good) and a6688f9cbb930ad139a7f3886684fcadeec59d30
(bad). I haven't had a chance to bisect yet. If someone has an educated guess which commit might be at fault, that will save me a lot of time :)
Tor 0.2.5.4-alpha-dev (git-95d47a74) Debian Jessie, kernel 3.14-1-amd64 libseccomp-dev 2.1.1-1
To repro:
- Enable sandbox, start tor.
- Open arm
- Observe that tor has crashed.
log:
Jun 08 02:04:20.000 [notice] New control connection opened.
============================================================ T= 1402207460
(Sandbox) Caught a bad syscall attempt (syscall getrlimit)
/usr/bin/tor(+0x123afa)[0x7f11e2773afa]
/lib/x86_64-linux-gnu/libc.so.6(getrlimit64+0x7)[0x7f11e0d771e7]
/lib/x86_64-linux-gnu/libc.so.6(getrlimit64+0x7)[0x7f11e0d771e7]
/usr/bin/tor(set_max_file_descriptors+0x2e)[0x7f11e276144e]
/usr/bin/tor(+0xd75d6)[0x7f11e27275d6]
/usr/bin/tor(+0x31ed0)[0x7f11e2681ed0]
/usr/bin/tor(connection_control_process_inbuf+0x1b44)[0x7f11e272d634]
/usr/bin/tor(+0xc8b55)[0x7f11e2718b55]
/usr/bin/tor(+0x34af1)[0x7f11e2684af1]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414)[0x7f11e1cdc184]
/usr/bin/tor(do_main_loop+0x195)[0x7f11e2686285]
/usr/bin/tor(tor_main+0x18d5)[0x7f11e2689245]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f11e0cbab45]
/usr/bin/tor(+0x32adb)[0x7f11e2682adb]
/usr/share/tor/tor-service-defaults-torrc:
DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
RunAsDaemon 1
User debian-tor
ControlSocket /var/run/tor/control
ControlSocketsGroupWritable 1
CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie
Log notice file /var/log/tor/log
torrc:
ORPort 9001
Sandbox 1
(I see getrlimit mentioned in the comments of legacy/trac#9894 (moved), not sure if same bug.)
Trac:
Username: alphawolf