Mailing List Archive: ocf_run: sanitize output before logging?

ocf_run: sanitize output before logging?

Nov 14, 2011, 12:53 PM

Post #1 of 4 (1405 views)

Dejan, Lars, and other shell gurus in attendance,

maybe I'm totally off my rocker, and one of you guys can set me
straight. But to me this part of the ocf_run function seems a bit fishy:

output=`"$@" 2>&1`
rc=$?
output=`echo $output`

Am I gravely mistaken, or would any funny control characters produced by
the wrapped command line totally mess up the content of "output" here as
it is mangled by the backticks?

What I'm noticing is the invocation of "ocf_run sipsak -v -s <uri>",
which we put into the asterisk RA as per Russell Bryant's suggestion,
seems to totally garble the output.

Compare this:

$ sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1
SIP/2.0 200 OK
Via: SIP/2.0/UDP
127.0.0.1:43665;branch=z9hG4bK.539207ad;rport=53485;alias;received=85.127.155.32
From: sip:sipsak@127.0.0.1:43665;tag=6dafacb9
To:
sip:somenotexistantextension@ekiga.net;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.3109
Call-ID: 1840229561@127.0.0.1
CSeq: 1 OPTIONS
Server: Kamailio (1.5.3-notls (i386/linux))
Content-Length: 0

To this:

$ output=`sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1`
$ echo $output
Content-Length: 0(1.5.3-notls
(i386/linux))tag=c64e1f832a41ec1c1f4e5673ac5b80f6.8ff585.127.155.32

In this case it appears to be due to carriage-return (0x0d, ^M)
characters that sipsak injects into its output, which is annoying but
relatively benign. But maybe we want to sanitize the ocf_run output
before we hand it off to be written to the logs?

Cheers,
Florian
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Re: ocf_run: sanitize output before logging? [ In reply to ]

dejan at suse

Nov 15, 2011, 7:21 AM

Post #2 of 4 (1363 views)

Permalink

Hi,

On Mon, Nov 14, 2011 at 09:53:12PM +0100, Florian Haas wrote:
> Dejan, Lars, and other shell gurus in attendance,
>
> maybe I'm totally off my rocker, and one of you guys can set me
> straight. But to me this part of the ocf_run function seems a bit fishy:
>
> output=`"$@" 2>&1`
> rc=$?
> output=`echo $output`

> Am I gravely mistaken, or would any funny control characters produced by
> the wrapped command line totally mess up the content of "output" here as
> it is mangled by the backticks?

I think you're not :) The last line was most probably put there
to convert CR to spaces.

> What I'm noticing is the invocation of "ocf_run sipsak -v -s <uri>",
> which we put into the asterisk RA as per Russell Bryant's suggestion,
> seems to totally garble the output.
>
> Compare this:
>
> $ sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP
> 127.0.0.1:43665;branch=z9hG4bK.539207ad;rport=53485;alias;received=85.127.155.32
> From: sip:sipsak@127.0.0.1:43665;tag=6dafacb9
> To:
> sip:somenotexistantextension@ekiga.net;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.3109
> Call-ID: 1840229561@127.0.0.1
> CSeq: 1 OPTIONS
> Server: Kamailio (1.5.3-notls (i386/linux))
> Content-Length: 0
>
> To this:
>
> $ output=`sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1`
> $ echo $output
> Content-Length: 0(1.5.3-notls
> (i386/linux))tag=c64e1f832a41ec1c1f4e5673ac5b80f6.8ff585.127.155.32

Seems like part of the output goes to stdout and another part to
stderr. The two are interspersed in an unpredictable manner.
Apart from saving the two separately, I'm not sure what can be
done.

> In this case it appears to be due to carriage-return (0x0d, ^M)
> characters that sipsak injects into its output, which is annoying but
> relatively benign. But maybe we want to sanitize the ocf_run output
> before we hand it off to be written to the logs?

Sanitize in the security sense? I guess that the log writer
should do that. Or make the message looks nicer? I'm all for
that, certainly.

Cheers,

Dejan

> Cheers,
> Florian
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Re: ocf_run: sanitize output before logging? [ In reply to ]

florian at hastexo

Nov 15, 2011, 8:50 AM

Post #3 of 4 (1362 views)

Permalink

On 2011-11-15 16:21, Dejan Muhamedagic wrote:
> Hi,
>
> On Mon, Nov 14, 2011 at 09:53:12PM +0100, Florian Haas wrote:
>> Dejan, Lars, and other shell gurus in attendance,
>>
>> maybe I'm totally off my rocker, and one of you guys can set me
>> straight. But to me this part of the ocf_run function seems a bit fishy:
>>
>> output=`"$@" 2>&1`
>> rc=$?
>> output=`echo $output`
>
>> Am I gravely mistaken, or would any funny control characters produced by
>> the wrapped command line totally mess up the content of "output" here as
>> it is mangled by the backticks?
>
> I think you're not :) The last line was most probably put there
> to convert CR to spaces.

>> $ output=`sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1`
>> $ echo $output
>> Content-Length: 0(1.5.3-notls
>> (i386/linux))tag=c64e1f832a41ec1c1f4e5673ac5b80f6.8ff585.127.155.32
>
> Seems like part of the output goes to stdout and another part to
> stderr. The two are interspersed in an unpredictable manner.

Unlikely.

If I do
$ output=`sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1`
$ xxd <<< $output

...then the output is in the hexdump in exactly the right order. It's
just delimited by CR (0x0d), not LF (0x0a). Which is mighty odd for a
utility running on any *nix platform, but still shouldn't be transformed
to something thus garbled, simply by being stuffed into a variable.

For now, I guess we'll wimp out and simply remove "-v" from the sipsak
invocation so it just doesn't produce any output, in which case ocf_run
falls back to logging just the command and its exit code.

Cheers,
Florian

--
Need help with High Availability?
http://www.hastexo.com/now
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Re: ocf_run: sanitize output before logging? [ In reply to ]

lars.ellenberg at linbit

Nov 16, 2011, 12:00 PM

Post #4 of 4 (1354 views)

Permalink

On Mon, Nov 14, 2011 at 09:53:12PM +0100, Florian Haas wrote:
> Dejan, Lars, and other shell gurus in attendance,
>
> maybe I'm totally off my rocker, and one of you guys can set me
> straight. But to me this part of the ocf_run function seems a bit fishy:
>
> output=`"$@" 2>&1`
> rc=$?
> output=`echo $output`
>
> Am I gravely mistaken, or would any funny control characters produced by
> the wrapped command line totally mess up the content of "output" here as
> it is mangled by the backticks?
>
> What I'm noticing is the invocation of "ocf_run sipsak -v -s <uri>",
> which we put into the asterisk RA as per Russell Bryant's suggestion,
> seems to totally garble the output.
>
> Compare this:
>
> $ sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP
> 127.0.0.1:43665;branch=z9hG4bK.539207ad;rport=53485;alias;received=85.127.155.32
> From: sip:sipsak@127.0.0.1:43665;tag=6dafacb9
> To:
> sip:somenotexistantextension@ekiga.net;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.3109
> Call-ID: 1840229561@127.0.0.1
> CSeq: 1 OPTIONS
> Server: Kamailio (1.5.3-notls (i386/linux))
> Content-Length: 0
>
> To this:
>
> $ output=`sipsak -v -s sip:somenotexistantextension@ekiga.net 2>&1`
> $ echo $output
> Content-Length: 0(1.5.3-notls
> (i386/linux))tag=c64e1f832a41ec1c1f4e5673ac5b80f6.8ff585.127.155.32
>
> In this case it appears to be due to carriage-return (0x0d, ^M)
> characters that sipsak injects into its output, which is annoying but
> relatively benign. But maybe we want to sanitize the ocf_run output
> before we hand it off to be written to the logs?

output=`echo $output` is there to make it one "line", I think.
Any funny control characters should not be a problem.

well, unless you echo them to a terminal.

ASCII NUL may be fun, though,
and will probably differ accross shel flavour and versions.

The terminal is also the "problem" you are seing there.
In a log file, it will all be one line, with some spurious "^M".

But on a terminal, well, CR is carriage return: start again at column 0.
so it just prints one line over the other, and the "trailing garbage"
is simply from the previous, longer lines.

Of course, you could do
output=`echo $output | cat -v`
instead, but it loses information.

If you are only bothered by CR, do
IFS=$' \t\r\n' output=`echo $output`
where $'' is most likely a bashism, but you get the idea.
A tr equivalent is obviously
output=`echo $output | tr -s ' \r' ' '`
(\t and \n have been squeezed already by the leaving off the ""
around $output)

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/