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

[Jonas Smedegaard]

Quoting Kalle Niemitalo (2015-07-30 11:09:44)
> Jonas Smedegaard <dr at jones.dk> writes in Bug#590544:
>> I don't know if Kannel not already spits out sensible errors in log 
>> messages, but if not then yes, that's a good suggestion to pass 
>> upstream.
>
> Regarding errors in log messages....
>
> If there is an error in /etc/kannel/kannel.conf (e.g. if it tries to 
> set a configuration variable that Kannel does not support), then 
> bearerbox fails not start, but the error message is not logged 
> anywhere in /var/log.  This makes the configuration error difficult to 
> find and fix.
> 
> strace shows that bearerbox tries to write error messages to stderr 
> but gets ENOSPC because run_kannel_box has redirected fd 2 to 
> /dev/full.

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


> As a workaround, one can run bearerbox in a tty and see the error 
> messages that way.  However, that requires a cumbersome invocation of 
> sudo or su if one wants the bearerbox process to get the same uid and 
> gid as when started from the init script.

Seems better if we could hack (or have upstream fix) run_kannel_box to 
behave more sensibly - or if there are sane use cases for it then fork 
and adapt for what is sensible as _init_ script.

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?


> If you're going to revise the init scripts, then perhaps you can get 
> rid of run_kannel_box altogether and instead have the init system 
> (systemd or whatever) restart the boxes if they die for any reason.  
> That way, the init system would also be in a position to log the 
> signal that killed the process.

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.


> There Kannel boxes can be configured to write their messages to 
> syslog, but AFAIK that requires setting the syslog-level variable in 
> kannel.conf, so it won't help if the problem is with kannel.conf 
> itself. Also, the messages written to /var/log/kannel/ often appear to 
> include passwords, so I'm wary of writing them to syslog.

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.


How does that all sound?  An, would you like to join the Debian Kannel 
team and collaborate directly on maintaining this package?  You need not 
formally be a Debian Developer to join our team.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-kannel-devel/attachments/20150730/befe9ff3/attachment.sig>