Alan DeKok wrote on 2016-07-06 15:13:

...

...

Tue Jul 5 13:16:42 2016 : Error: Cannot update core dump limit: Operation not permitted Tue Jul 5 13:16:42 2016 : Info: Core dumps are enabled Tue Jul 5 13:16:42 2016 : Info: Debugger not attached Any idea what's going wrong here? The server is probably changing UID, and trying to update the core limit after that.

I guess that's not a problem (since FR does a prctl(PR_SET_DUMPABLE, 1) after the UID/GID changes):

setgroups(1, [106]) = 0 setgid(106) = 0 mkdir("/var/log/freeradius", 0700) = -1 EEXIST (File exists) geteuid() = 0 setresuid(4294967295, 104, 0) = 0 geteuid() = 104 setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = 0 open("/var/log/freeradius/radius.log", O_WRONLY|O_CREAT|O_APPEND, 0640) = 3 fchown(3, 104, 106) = 0 prctl(PR_SET_DUMPABLE, 1) = 0 setrlimit(RLIMIT_CORE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = -1 EPERM (Operation not permitted)

but FR uses setrlimit() with rlim_max=0, and you can only lower rlim_max, but not raise it (unless you have the CAP_SYS_RESOURCE capability). I don't know what the call setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) is good for...

Alan DeKok wrote on 2016-07-07 14:38:

...

but FR uses setrlimit() with rlim_max=0, and you can only lower rlim_max, but not raise it (unless you have the CAP_SYS_RESOURCE capability). I don't know what the call setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) is good for... If you have given it the capability, you can get core dumps.

And how would you suggest I should do that? freeradius is started as root, so the capability is there at start time. As I wrote, the code explicitely sets the hard limit for the core size to zero, so there is no chance for the unprivileged freeradius user to raise them again. Why is the server doing that??

On 13 Jul 2016, at 08:58, Alan DeKok <aland@deployingradius.com> wrote:

On Jul 13, 2016, at 8:06 AM, Jakob Hirsch <jh@plonk.de> wrote: dumps.

...

And how would you suggest I should do that? freeradius is started as root, so the capability is there at start time.

If you set "allow_core_dumps = yes" it should work.

...

As I wrote, the code explicitely sets the hard limit for the core size to zero, so there is no chance for the unprivileged freeradius user to raise them again. Why is the server doing that??

Honestly... no idea.

All of that debugger / core dump code was re-written by Arran. It *should* work, but I've had all kinds of problems with it.

Even split between code issues, PEBCAK, poor communication. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On Jul 13, 2016, at 10:46 AM, Alan DeKok <aland@deployingradius.com> wrote:

...

On Jul 13, 2016, at 10:28 AM, Jakob Hirsch <jh@plonk.de> wrote:

Arran Cudbard-Bell wrote on 2016-07-13 15:17:

...

...

but FR uses setrlimit() with rlim_max=0, and you can only lower rlim_max, but not raise it (unless you have the CAP_SYS_RESOURCE capability). OK... So there's probably an issue there. Could we get the stack trace so it's clear what logic is being executed.

Sure:

This code is run before the configuration is read:

{ char const *panic_action = NULL;

panic_action = getenv("PANIC_ACTION"); if (!panic_action) panic_action = main_config.panic_action;

if (panic_action && (fr_fault_setup(panic_action, argv[0]) < 0)) { fr_perror("Failed configuring panic action: %s", main_config.name); fr_exit(EXIT_FAILURE); } }

Note that main_config.panic_action will always be NULL here. Because it hasn't read the configuration files yet.

The solution is to have an "initialization" function which is separate from the "do work" function.

That code doesn't touch the dumpable flag or rlim_cur or rlim_max, or initialize anything to do with core dumps, the core dump code just happens to exist in the same src file as fr_fault_setup. OP's idea of not setting rlim_max will work. We need to be able to change rlim_cur, because IIRC, the process needs to be temporarily 'dumpable' in order for PATTACH to work in some cases. A big part of why the code in debug.c is so complex, is because the Linux/BSD/POSIX APIs for controlling this stuff are awful. Whether the process can have its core dumped or not should affect whether you can attach a debugger to it, but it does. There's three different facilities all controlling a slightly different part of this functionality: - Linux CAP API - Controls user/process permissions like PATTACH. - get/set rlimit - Controls the size of cores and transitively whether core dumps are allowed. - PRCTRL - Bool - Again whether core dumps are allowed. So get/set rlimit do essentially the same thing as PR_SET_DUMPABLE, I guess PR_SET_DUMPABLE must have some interaction with CAP, that get/set rlimit doesn't... There's no good test for whether a process is currently being debugged either. We attempt a PATTACH to try and figure it out, but that doesn't always work, because we might not have CAP permissions to do that, even though the process is trying to attach to itself. It makes absolutely no sense. fr_fault_setup needs to be run once before we read the config (to set the panic action from the environment), and once after (if the config specifies a panic action), to set the new panic action. Its position in radiusd.c was changed recently, because the debug callbacks weren't being installed early enough to catch issues in the dictionary code. The code needs to be changed so it's called a second time in mainconfig.c with the new panic_action (if one was provided). I'm going to split the debug code and the core dump control code into separate files to make it easier to see what's going on. They're not really related. -Arran