panic_action / ptrace: Operation not permitted
Hi, I'm currently configuring the shiny new panic_action handler on my 3.0.2 system. The server runs as radiusd:radiusd. When I send it a kill -SEGV to try the panic_action, the resulting log file tells me: # cat gdb-radiusd-27780.log Reading symbols from /usr/local/freeradius/3.0.2/sbin/radiusd...done. Attaching to program: /usr/local/freeradius/3.0.2/sbin/radiusd, process 27780 ptrace: Operation not permitted. //27780: No such file or directory. /usr/local/freeradius/config/raddb/panic.gdb:1: Error in sourced command file: No frame selected. (gdb) quit The gdb session is started as radiusd (I guess; after all the running process dropped its root priv right after starting). So... I can't ptrace my own process? Why, thank you! I ran the panic_action command-line as root on a running process - and get the ptrace just fine. I read up on this on Google, and found that this would typically be a problem when using the "yama" security module, which I don't (there is no /proc/sys/kernel/yama subdir). This is a very recent system, openSUSE 13.1 with current patchlevel. The kernel is the shipped SuSE-flavoured "default" kernel. Before I dig into running a vanilla kernel to see if there's SUSE magic happening on their flavour - am I looking at the wrong place? Is this problem known and solved? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
I ran the panic_action command-line as root on a running process - and get the ptrace just fine.
I read up on this on Google, and found that this would typically be a problem when using the "yama" security module, which I don't (there is no /proc/sys/kernel/yama subdir).
This is a very recent system, openSUSE 13.1 with current patchlevel. The kernel is the shipped SuSE-flavoured "default" kernel.
Before I dig into running a vanilla kernel to see if there's SUSE magic happening on their flavour - am I looking at the wrong place? Is this problem known and solved?
I had the yama problem on ubuntu, and poking the relevant file in the yama subdir solved it. But if you're not running yama... hmm. OK, someone reporting *exactly* the same problem back in 2008 on the GBD list. Here is the fix they helpfully posted: https://www.sourceware.org/ml/gdb/2008-01/msg00246.html Here's the original message: http://lists.gnu.org/archive/html/bug-gdb/2008-01/msg00002.html Googlefoo! Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
I had the yama problem on ubuntu, and poking the relevant file in the yama subdir solved it. But if you're not running yama... hmm.
OK, someone reporting *exactly* the same problem back in 2008 on the GBD list.
Here is the fix they helpfully posted: https://www.sourceware.org/ml/gdb/2008-01/msg00246.html
Here's the original message: http://lists.gnu.org/archive/html/bug-gdb/2008-01/msg00002.html
Googlefoo!
suid? Well, worth a try, so I did - but I still get the same problem. It's also a bit awkward: if this were a default kernel security measure, would it not *consistently* fail to work on all recent Linuxes? Am I the only one using the default "production system" panic_action? Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 1 Apr 2014, at 15:25, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
I had the yama problem on ubuntu, and poking the relevant file in the yama subdir solved it. But if you're not running yama... hmm.
OK, someone reporting *exactly* the same problem back in 2008 on the GBD list.
Here is the fix they helpfully posted: https://www.sourceware.org/ml/gdb/2008-01/msg00246.html
Here's the original message: http://lists.gnu.org/archive/html/bug-gdb/2008-01/msg00002.html
Googlefoo!
suid? Well, worth a try, so I did - but I still get the same problem.
It's also a bit awkward: if this were a default kernel security measure, would it not *consistently* fail to work on all recent Linuxes? Am I the only one using the default "production system" panic_action?
It works fine for me on OSX (10.9.1) and the the yama detection disabled on ubuntu 13.07. We've used it at customer sites to send out automatic emails when the hosts have gone down with the backtraces, and it seems to work there too (ubuntu 12.04). Not really sure what else to suggest, sorry. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
It works fine for me on OSX (10.9.1) and the the yama detection disabled on ubuntu 13.07.
We've used it at customer sites to send out automatic emails when the hosts have gone down with the backtraces, and it seems to work there too (ubuntu 12.04).
Not really sure what else to suggest, sorry.
Well, I found it now :-) My config had security.allow_core_dumps = no. As it happens, that setting is entangled with panic_action's gdb attach. allow_core_dumps modifies PR_SET_DUMPABLE. From the man page of prctl: "PR_SET_DUMPABLE (since Linux 2.3.20) [... bla bla ...] Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH." So, my bad for producing an inconsistent configuration ;-) It would be very nice if the comments near panic_action could give users a hint though "If your panic_action uses gdb attach (such as the examples below), remember to allow core dumps for this to work (security.allow_core_dumps)." That would avoid some amount of guesswork :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 2 Apr 2014, at 07:55, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
It works fine for me on OSX (10.9.1) and the the yama detection disabled on ubuntu 13.07.
We've used it at customer sites to send out automatic emails when the hosts have gone down with the backtraces, and it seems to work there too (ubuntu 12.04).
Not really sure what else to suggest, sorry.
Well, I found it now :-)
My config had security.allow_core_dumps = no.
As it happens, that setting is entangled with panic_action's gdb attach.
allow_core_dumps modifies PR_SET_DUMPABLE. From the man page of prctl:
"PR_SET_DUMPABLE (since Linux 2.3.20) [... bla bla ...] Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH."
So, my bad for producing an inconsistent configuration ;-)
Ah it's fine :P
It would be very nice if the comments near panic_action could give users a hint though "If your panic_action uses gdb attach (such as the examples below), remember to allow core dumps for this to work (security.allow_core_dumps)."
That would avoid some amount of guesswork :-)
I just fixed the code to set the dumpable flag, even easier :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Stefan Winter