Re: how to redirect glibc's dump output ? (stack 'backtrace', etc)

["Linda A. Walsh" <gnu at tlinx dot org>]

Ãngel GonzÃlez wrote: 
> I do find useful that the error is dumped to the screen. I am sure 
> that if it would
> go to eg. core.txt many of those would go unnoticed (even the 
> developer may
> not be expecting a segfault, and the program could be segfaulting at a 
> closing
> procedure). 
----
Why not "Segmentation fault" core+backtrace dumped.

I.e. I'm not talking about suppress ALL error message, just all the detail.

=======================================================

Paul Pluzhnikov wrote:
> I've been told that there are also security reasons for why messages
> don't go to STDERR by default: if an external user could run some
> program on your machine (e.g. via cgi-bin) and observe an error
> report, he then have way more info than you want him to have.
----
   If you are suggesting that the error be dumped to a file for
security reasons, I AGREE!.   But the current behavior is to dump
it to the USER's TTY... which cannot be anymore secure (likely less
if anything) than dumping it to stderr.

   If you are saying that dumping the backtrace gives information
to hackers, then dumping it to the screen is already a security flaw and
by that, you would be seem to be saying that the current behavior
is a security risk, that would make this a security flaw?  Is that
what you are saying?


> The (numeric) stacktrace is useless without the memory map if you have
> relocatable objects (shared libraries or a PIE executable) that took
> part in the crash.
The stacktrace AND the relocatable are useless for *most* people (on the
assumption that there are far greater numbers of "users" as opposed
to "developers" that will be using the program).


If a devel. wantes backtrace (and memory map) info, they can sump core with
SYMBOLS*, and get a stacktrace that way.

My program HAS full symbols.  If a stack trace to the user's screen
is "mandatory" on the grounds that it is "useful" to some set of people
(what do you bet that it is less than .1% of users), then why
are you not dumping the symbols as well?  My program was running
with full symbols compiled in.

Any argument against including full symbols would seem to
apply to what is currently dumped (backtrace+memmap).


--
Note, that doesn't mean the current behavior shouldn't
be selectable via some ENV option, just that the backtrace and
memory map are both *developer* output.  They shouldn't be displayed
by default (to users) in any event.  Even a memory map and trace
back could be extra information used by a hacker.

From a security standpoint, you don't want to be dumping any information
other than the fact that an error occurred and and some error id
that would allow a developer to uniquely know what the error was

Example: the user accessible information tells should tell you where
the error occurrd (filename+offset)... so in main program or library,
the information you wanted from the memory map has been satisfied.

Does that clarify what I'm saying more?