[ Charles, please read to the bottom of this... 8-]

> It was pointed out by me already 8 years ago:
> 
>    "[...] core-dumps as default is an evil thing.  There should be
>     some way to >enable< core-dumps when you want them, rather than
>     have them as default.  This would also solve security issue 
>     where a core-dump may contain sensitive information. [...]"
> 
> What we need is really a new syscall:
> 
> 	procctl(pid, function, arg)
> [ ... ]

I disagree.

(1) that means that people writing and debugging programs can no
longer as easily get core dumps to help them debug.  (They have to add
a system call, and a non-standard one at that, to enabled core dump
functionality.)

(2) that means that non-repeatable crashes, especially of 'standard'
system utilities, will be almost impossible to track down, unless you
globally enable core dumps or enable core dumps for individual system
utilties (thus defeating the purpose, either completely or partially,
of your proposed change).  It also means that Joe Bob, a random user,
can't say "cat dumped core on me, here's the core, what happened?" to
people attempting to support his use of the system.

(3) It's different from other UNIX systems.


Given (1) and (3), i.e. the traditional and 'normal' UNIX program
behaviour that developers expect to see, making a change like this is
developer-hostile.

(2) would be a pain in _my_ butt, for one, because (on NetBSD/Alpha)
core dumps of random utilities are still too common (damn stupid
programmers, long != 32 bits!!!), and i end up doing "enough" core
groveling...



Charles, re: "is a core dump on this weird file system safe"?
Actually, a good solution there might be a "NOCOREDUMP" mount flag, a
la NOSUID and NOEXEC.  That has several advantages:

(1) Configurability of security policy:  The system manager knows if
the remote file system is "safe," and can do the right thing.  Even
disregarding AFS, think of the case of NFS over a potentially snooped
net.  (Sure, you could be losing badly there anyway, but simple
snooping is harder to notice than packet forgery, in most cases.)

(2) File system lossage prevention: ever dump a 10M core to AFS?
On several AFS ports, that'll hang AFS.  This provides a common-case
workaround.

(3) it's easy to implement.

It's not a general, fail-safe solution to the problem, but I don't
think the thought shouldn't be discarded out of hand.  I'd say that
it'd solve the problems that most people need solved, if they care
enough to set the flag.


chris