[Pkg-kannel-devel] Bug#794065: Bug#794065: kannel: run_kannel_box prevents logging of kannel.conf errors

Kalle Niemitalo kalle.niemitalo at procomp.fi
Fri Jul 31 18:15:19 UTC 2015


Jonas Smedegaard <dr at jones.dk> writes:

> Oh my... Do you know if upstream is already aware of that issue?

I found these in redmine:

  https://redmine.kannel.org/issues/116
  "run_kannel_box should be deprecated in favor of --parachute"

  https://redmine.kannel.org/issues/69
  "Patch to provide syslog support to run_kannel_box"

and from mailing lists:

  http://article.gmane.org/gmane.comp.mobile.kannel.user/10727
  Subject: RE: disable output to stdout

  http://article.gmane.org/gmane.comp.mobile.kannel.devel/24815
  Subject: Re: run_kannel_box - forcing umask to be 077
  "please stop using run_kannel_box because it's deprecated"

> It might be as simple as commenting out line run_kannel_box.c line 393 
> (calling rebind_standard_streams() ), but I would love someone else than 
> me to hack it - someone more fluent in C and knows the details of what 
> exactly is needed to spawn a background process reliably.  You, perhaps?

Because run_kannel_box is apparently deprecated, I don't think
I should spend my employer's time on improving it.

> I don't like the "for any reason" - I can imagine sane reasons for dying 
> that shouldn't be turned into init system looping like crazy.

sysvinit is able to respawn processes listed in /etc/inittab if they
die, and there is a "respawning too fast: disabled for %d minutes"
limit.  This "respawn" feature of sysvinit is normally used only for
getty and sulogin, but the equivalent feature of Upstart seems to be
used for pretty much any service one wants to keep running.  I'm not
familiar with systemd but I imagine it too has something similar.

> Makes sense to leak passwords at debug-grade verbosity levels.
>
> If code leaks passwords at less verbose levels, we should patch that 
> (and make upstream aware).
>
> If default config/init sets debug-grade verbosity we should fix that.
>
> Other than that we can perhaps add comment in config file to warn about 
> such leakage when raising verbosity.

OK.  Currently though, the files in /var/log/kannel are not
world-readable, so writing passwords there is not too bad.

> An, would you like to join the Debian Kannel 
> team and collaborate directly on maintaining this package?

I'd rather not.  I intend to stop fixing Kannel bugs when I get it
working sufficiently well in my employer's environment.



More information about the Pkg-kannel-devel mailing list