Assuming that the default coredump size limit is a soft limit of "0" and a hard limit of "unlimited", this can be reproduced by running:

 $ ulimit -c unlimited
 $ ulimit -c
 unlimited
 $ sudo bash -c 'ulimit -c'
 unlimited

Wheras the expected output would be
 $ sudo bash -c 'ulimit -c'
 0

This surprising change in behavior was introduced by this commit, which tries to make sure that sudo can't dump core, by using the PR_SET_DUMPABLE prctl call on Linux:

commit f57629c95308cb87da059c37722bb8b65217f318
Author: Todd C. Miller <Todd.Miller@courtesan.com>
Date:   Thu Apr 27 12:28:08 2017 -0600

    On Linux, if the command we ran dumped core, set PR_SET_DUMPABLE
    to 0.  This will prevent sudo itself from dumping core in this case.



The problem appears to be, that disable_coredump(true) now gets called at a later point, where it actually overwrites the coredump size limits that have been set via pam_limits.so (e.g. when it applies the settings from /etc/security/limits.conf).

So at least the setrlimit(RLIMIT_CORE, &corelimit) portion of the disable_coredump(true) function call should happen at an earlier stage in the code.


As a workaround for this bug, the disable_coredump flag can be set to False in sudo.conf.