[Pkg-net-snmp-devel] Bug#932775: Bug#932775: snmpd: init script does not respect /etc/default/snmpd

[Daniel Reichelt]

Hi Craig,

> It's a little more complicated than that. The defaults are loaded in>
> by init-d-script but are then overwritten by the snmp init script.

Whoops…I totally missed the usage of init-d-script. Shouldn't be writing
bug reports that late…



> Actually looking at the init script, it does check SNMPOPTS is set
> and this is the only variable in the default file. What exactly is
> not getting picked up or overwritten?

My /etc/defaults/snmpd looks like this:

------8<---------
SNMPDOPTS='-LS5d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I
-smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'
------8<---------

Notice -Ls5d versus the default of -Lsd...this doesn't get picket up and
snmpd is started with the defaults.


Here's my analysis using a somewhat fresher head:

- user calls /etc/init.d/snmpd
- init-d-script is sourced
- init-d-script does its magic and itself sources /etc/init.d/snmpd again
- this time around init-d-script does not get called and snmpd actually
executes DAEMON_ARGS="$SNMPDOPTS -p $PIDFILE". However, at this point,
$SNMPDOPTS has not been set yet.
- snmpd continues, declares do_start_prepare()
- init-d-script continues and only *now* /etc/default/snmpd gets
sourced, thereby picking up on my custom $SNMPDOPTS...which doesn't get
used any more.
- init-d-script calls do_start_prepare() <-- this one's important for
the fix
- init-d-script calls do_start_cmd(), which calls start-stop-daemon with
DAEMON_ARGS still containing the wrong SNMPDOPTS


My new fix is to move the assignment of DAEMON_ARGS into
do_start_prepare(). That way, the assignment happens *after* $SNMPDOPTS
possibly got set by /etc/default/snmpd.



I compiled bash with the fix for CVE-2016-7543 ($PS4 vulnerability)
reverted and got a much more informative trace than I got before just by
running the original bash -x under root.

Please find attached two traces. First, I set PS4:

# export PS4='\t:${BASH_SOURCE}:${LINENO}:${FUNCNAME[0]}
[${SHLVL},${BASH_SUBSHELL}, $?] '

Then I created the traces by invoking

# bash-vulnerable-PS4 -x /etc/init.d/snmpd start

twice. The orig.log contains the trace running the unchanged init
script, while patched.log contains a trace running it having the
attached patch applied. This should make thinks clearer.


Hauler if you have questions!


Cheers
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orig.log
Type: text/x-log
Size: 11298 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-net-snmp-devel/attachments/20190725/ec39ceac/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patched.log
Type: text/x-log
Size: 11338 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-net-snmp-devel/attachments/20190725/ec39ceac/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snmpd.diff
Type: text/x-patch
Size: 615 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-net-snmp-devel/attachments/20190725/ec39ceac/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-net-snmp-devel/attachments/20190725/ec39ceac/attachment-0001.sig>