When you implement set-capability using the
"pass" facility described in snmpd.conf you run into
a peculiar problem if the OBJECT-TYPE of the
VarBind is OCTET STRING or a derivative.
The problem is that the value argument to the
EXEC program is quoted when the command
arguments are built, then split on spaces without
regards to quotes after the subprocess is forked,
but before it is execv'ed.
This means that
snmpset .... <oid> s oneword
invokes the EXEC program with four arguments
(Ooops. who added those quotes) whereas
snmpset ... <oid> s "two words"
invokes the EXEC program with *five* arguments
which is definitely not what one would expect from
I haven't checked, but I am certain that
snmpset ... <oid> x 200020
(an OCTET STRING with spaces and zero value
OCTET) won't do what one would expect, either. It
will probably make a three argument invocation.
I can't think of a simple way to save this situation,
and certainly not one that is backwards
compatible. Part of the problem is that the utility
functions (exec_command, get_exec_output) are
used for other purposes, so their semantics can't
just be changed. One would probably need to
define a new snmpd.conf entry ("pass_new"?
Arrghh!) with a more consistent semantic for
OCTET STRING, document the new and the old
semantics and define variants of the utility
functions that allows for the building of a real
execv argument, not a string that is split on spaces
just before the execv.