There seems to be a lot of confusion about the security issues here,
so I will give a quick summary.

* Zeroing DB buffers is at best a partial solution to the security
issues raised.  It does not deal with stdio buffers or RPC buffers.
It does not deal with temporary data areas used by such things as
sorting routines.

* There are probably a number of cases where a process can be sent a
signal that would normally cause a core dump, while it still has
sensitive data.  A program using sensitive data should be aware of
this and prevent itself from core dumping.  However, there are cases
where a process may not be able to know this, because a library may
have external storage that it doesn't know about.

* As an added check, in NetBSD, a process may not core dump if it has
ever changed its IDs since (or during) the most recent exec; this is
intended to insure that any data fetched by a set-id program is
removed.  However, this is *not* a complete solution in itself,
because it's possible for a set-id program to call another one, which
would not have this protection.  (The set-id program could of course
disable core dumping before calling the program, so it does have a way
around this.)

* In the particular case of ftpd, if you've logged in as a user other
than root, then your saved, real, and effective uids do not match, so
the previous check we used to use (ruid != svuid || ruid != euid)
would catch this.  So, unless you're logged in as root, you'd be hard
pressed to get ftpd to core dump.

* Although core dumps are written with mode 0600, this is not secure
in all environments.  In particular, it may be written out over NFS
(and thus sent over the wire in cleartext), or it may be written out
to AFS (for which the mode means more or less nothing, and which may
also be snooped if encryption is not enabled).

It seems to me that a general tainting algorithm for deciding when a
program has sensitive data, and preventing core dumps during those
times, is what we really need.  Questions to consider:

* Do you prevent core dumps if you've ever had any tainted data, or do
you attempt to decide when you no longer have any?

* If the latter, how?  Always zero buffers (including partial zeroing
of stdio buffers as you read from them!), create new interfaces to the
libraries to inform them which data is secure, etc?  Garbage
collection?  B-)

I invite people to start a (sane) dialog on this issue.