How to get sudo to dump core?

Alan Sparks asparks at
Fri Jun 27 10:21:36 EDT 2003

Got the backtrace.  Running a 'bt' now shows the following:
#0  0xff3c3614 in ?? ()
#1  0xff3c36c8 in ?? ()
#2  0xff3c3994 in ?? ()
#3  0xff3c14b0 in ?? ()
#4  0xff3c15b8 in ?? ()
#5  0xff371c74 in pam_end () from /usr/lib/
#6  0x1cd68 in pam_prep_user ()
#7  0x19024 in set_perms_suid ()
#8  0x18e64 in set_perms_suid ()
#9  0x19b64 in main ()

Not that I'm sure what it's telling me, other that things went really
weird in pam_end().  Wonder if that has been changed in an incompatible
way by Sun in their latest patches...?

On Fri, 2003-06-27 at 04:26, mlh at wrote:
> On 26 Jun 2003 12:50:23 -0600
> Alan Sparks <asparks at> wrote:
> > Is there a way to get sudo to dump core on a segfault?
>  for the sudo limitation, see Todd's reply.  For Solaris, see
> Enabling setuid Programs to Produce Core Files
> You can use the coreadm command to enable or disable setuid programs to produce core files for all system processes or on a per-process basis by setting the following paths:
>     *
>       If the global setuid option is enabled, a global core file path allows all setuid programs on a system to produce core files.
>     *
>       If the per-process setuid option is enabled, a per-process core file path allows specific setuid processes to produce core files.
> By default, both flags are disabled. For security reasons, the global core file path must be a full pathname, starting with a leading /. If superuser disables per-process core files, individual users cannot obtain core files.
> The setuid core files are owned by the superuser with read/write permissions for the superuser only. Ordinary users cannot access them even if the process that produced the setuid core file was owned by an ordinary user.
> See coreadm(1M) for more information.
Alan Sparks, Sr. UNIX Administrator	asparks at
Quris, Inc.				(720) 836-2058

More information about the sudo-users mailing list