panic_action and GDB/LLDB

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue Nov 4 18:13:36 CET 2014


The server now performs checks to determine whether it is running under gdb or lldb,
and if it is, will not install the signal handlers required for panic_action to
functions.

We found that signal handlers for fatal signals interfered with debugger operation,
and meant we couldn't get back traces or do interactive debugging under various 
crash conditions.

The detection mechanism is basically:
#ifndef HAVE_SYS_PTRACE_H
* can't determine debug state, so install the signal handlers - end
#endif
#ifdef HAVE_CAPABILITY_H
* check whether we currently have the CAP_SYS_PTRACE capability
* if no, we can't determine debug state, so install the signal handlers - end
#endif
* fork a child with a pipe between parent and child
* have the child attempt to ptrace the parent
* if it can parent pauses execution
  * child writes a status code (to the pipe) indicating that
  * child detaches
  * parent resumes and reads status code
  * signal handlers are installed - end
* if it can't then the process is being debugged
  * child writes a status code (to the pipe) indicating that
  * don't install signal handlers - end

If anyone knows of another universally applicable method to determine if a process is
being debugged then i'd be interested to implement it, but the hacky ptrace technique is
the best I could come up with.

If you're debugging and not running as the root user (which always has CAP_SYS_PTRACE),
you can set the capability on the radius binary using:

  setcap cap_sys_ptrace+ep <path to radiusd bindary>

Using setcap on gdb/lldb would also allow to use those utilities without being root.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2



More information about the Freeradius-Devel mailing list