openssh unix dev - Sep 2003 - Possible new configure option: --with-fatal-coredumps?

Hi all.
	What's the feeling about adding a new configure-time option to generate a
core dump on when fatal() is called?

	It might help debug certain types of problems, but runs the risk of
sensitive information being left in the core dump.  Obviously, it should
default to "no".

	Anyone like the idea?  Anyone hate it?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: acconfig.h
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh_cvs/acconfig.h,v
retrieving revision 1.165
diff -u -p -r1.165 acconfig.h
--- acconfig.h	8 Sep 2003 21:35:17 -0000	1.165
+++ acconfig.h	12 Sep 2003 10:05:51 -0000
@@ -421,6 +421,9 @@
 /* Define if HEADER.ad exists in arpa/nameser.h */
 #undef HAVE_HEADER_AD
 
+/* Enable core dumps on fatal errors */
+#undef WITH_FATAL_COREDUMPS
+
 @BOTTOM@
 
 /* ******************* Shouldn't need to edit below this line
************** */
Index: configure.ac
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v
retrieving revision 1.150
diff -u -p -r1.150 configure.ac
--- configure.ac	11 Sep 2003 04:42:56 -0000	1.150
+++ configure.ac	12 Sep 2003 10:27:24 -0000
@@ -2398,6 +2398,14 @@ AC_ARG_WITH(lastlog,
 		fi
 	]
 )
+AC_ARG_WITH(fatal-coredumps,
+    [  --with-fatal-coredumps  Create core dumps on fatal errors [no]],
+	[
+		if test "x$withval" = "xyes" ; then	
+			AC_DEFINE(WITH_FATAL_COREDUMPS)
+		fi
+	]
+)
 
 dnl lastlog, [uw]tmpx? detection
 dnl  NOTE: set the paths in the platform section to avoid the
Index: fatal.c
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh_cvs/fatal.c,v
retrieving revision 1.1
diff -u -p -r1.1 fatal.c
--- fatal.c	26 Feb 2002 19:24:22 -0000	1.1
+++ fatal.c	12 Sep 2003 09:54:15 -0000
@@ -36,5 +36,8 @@ fatal(const char *fmt,...)
 	va_start(args, fmt);
 	do_log(SYSLOG_LEVEL_FATAL, fmt, args);
 	va_end(args);
+#ifdef WITH_FATAL_COREDUMPS
+	abort();
+#endif
 	fatal_cleanup();
 }

On Fri, Sep 12, 2003 at 09:12:48PM +1000, Darren Tucker
wrote:
> Hi all.
> 	What's the feeling about adding a new configure-time option to
generate a
> core dump on when fatal() is called?
> 
> 	It might help debug certain types of problems, but runs the risk of
> sensitive information being left in the core dump.  Obviously, it should
> default to "no".
> 
> 	Anyone like the idea?  Anyone hate it?
i like the idea, but it should also try to enable compile with
-g or something similar.

On Fri, 12 Sep 2003, Darren Tucker wrote:
> Hi all.
> 	What's the feeling about adding a new configure-time option to
generate a
> core dump on when fatal() is called?
Are all calls to fatal() considered "this shouldn't happen" cases
?  I'm
sure I've seen cases where fatal() is called that are "normal
operation"
but it is time to drop the connection, eg an auth failure.

--
Darren J Moffat