Mailing List Archive: Linux-HA: Dev

ocf_run: sanitize output before logging?

Index | Next | Previous | View Threaded

florian at hastexo

Nov 14, 2011, 12:53 PM

Post #1 of 4 (267 views)
Permalink

ocf_run: sanitize output before logging?

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 [at] ekiga 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 [at] 127:43665;tag=6dafacb9
To:
sip:somenotexistantextension [at] ekiga;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.3109
Call-ID: 1840229561 [at] 127
CSeq: 1 OPTIONS
Server: Kamailio (1.5.3-notls (i386/linux))
Content-Length: 0

To this:

$ output=`sipsak -v -s sip:somenotexistantextension [at] ekiga 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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejan at suse

Nov 15, 2011, 7:21 AM

Post #2 of 4 (250 views)
Permalink

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

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 [at] ekiga 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 [at] 127:43665;tag=6dafacb9
> To:
> sip:somenotexistantextension [at] ekiga;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.3109
> Call-ID: 1840229561 [at] 127
> CSeq: 1 OPTIONS
> Server: Kamailio (1.5.3-notls (i386/linux))
> Content-Length: 0
>
> To this:
>
> $ output=`sipsak -v -s sip:somenotexistantextension [at] ekiga 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 [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

florian at hastexo

Nov 15, 2011, 8:50 AM

Post #3 of 4 (249 views)
Permalink

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

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 [at] ekiga 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 [at] ekiga 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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lars.ellenberg at linbit

Nov 16, 2011, 12:00 PM

Post #4 of 4 (243 views)
Permalink

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

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 [at] ekiga 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 [at] 127:43665;tag=6dafacb9
> To:
> sip:somenotexistantextension [at] ekiga;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.3109
> Call-ID: 1840229561 [at] 127
> CSeq: 1 OPTIONS
> Server: Kamailio (1.5.3-notls (i386/linux))
> Content-Length: 0
>
> To this:
>
> $ output=`sipsak -v -s sip:somenotexistantextension [at] ekiga 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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads