Automatic backtrace [Was: Re: NetAPP/Samba 3.0/plugs]

Martin Pool mbp at
Wed Mar 13 16:51:05 GMT 2002

On 13 Mar 2002, Scott Gifford <sgifford at> wrote:
> Andrew Bartlett <abartlet at> writes:
> > Scott Gifford wrote:
> > > Andrew Bartlett <abartlet at> writes:
> > > > Scott Gifford wrote:

> > > > > Perhaps I'm missing something obvious, but why not just let Samba dump
> > > > > core?...It's straightforward to provide a backtrace from a core file.
> > > >
> > > > Where?  Under what uid?  Following what symlinks?
> > > 
> > > All of this is handled by the OS, and core is dumped in the current
> > > working directory.  I don't know how Samba decides what directories to
> > > chdir() into, but if it wanders around a bit, something like
> > > chdir("/some/known/directory"); abort(); in a signal handler will make
> > > sure that the corefile ends up in a sane place.
> > 
> > But as what user?  And it must work perfectly across 30 different
> > operating systems.  A sig11 that has us compleatly hosed must not be
> > able to affect where/how we dump core. 
> A setuid() could select which user, and:
>     setuid(0);
>     chdir("/static/string");
>     abort(); 
> is pretty standard stuff, and pretty likely (even if not guaranteed)
> to work in a signal handler.  But at any rate...

Apache does this, and it's configurable by the CoreDumpDirectory
configuration option.  Their situation is slightly different, because
after startup the server runs only as a single uid.

  /* handle all varieties of core dumping signals */
  static void sig_coredump(int sig)
      signal(sig, SIG_DFL);
  #if !defined(WIN32) && !defined(NETWARE)
      kill(getpid(), sig);
      /* At this point we've got sig blocked, because we're still inside
       * the signal handler.  When we leave the signal handler it will
       * be unblocked, and we'll take the signal... and coredump or whatever
       * is appropriate for this particular Unix.  In addition the parent
       * will see the real signal we received -- whereas if we called
       * abort() here, the parent would only see SIGABRT.
To guard against revealing passwords, you could also stat(".") after
the chdir, and check uid==0, mode==0700.

Possibly there is some security reason why it's not appropriate, but i
can't see it.

At the risk of being too clever, we could also mkdir(getpid()), to
capture multiple core files on platforms that do not have a mechanism
for setting the corefile name.

> > In any case, the user who understands what a 'core' does is not the
> > target audience.  The target audience is the user who gets a Panic and
> > doesn't know much more than how to send us a logfile.  

I've seen some situations where even though the user could not use a
corefile themselves they would know what to do with one.  It's also
not that hard for people to learn how to e.g. get a backtrace out --
you can see plenty of examples of this on the debian or gnome bug


More information about the samba-technical mailing list