Viktor Dukhovni:
> > On 16 Feb 2022, at 1:20 pm, Wietse Venema <wie...@porcupine.org> wrote:
> >
> >> Actually, no, with "-r" not only are quotes removed, but also escaped
> >> forms are converted back to the underlying UTF-8 form, and control
> >> characters are output verbatim (as newlines, ESC, ...).
> >
> > Oops, I did an incorrect experiment.
> >
> > Confirming that -r produces unescaped output:
> >
> > $ cat x
> > { "foo": "\nbar"}
> > $ jq -r .foo x|od -cb
> > 0000000 \n b a r \n
> > 012 142 141 162 012
> >
> > So, "jq -r" expands \n into newline. What is the legitimate need
> > to pass such things into scripts that expect newline-delimited output?
>
> Well, if a message contains non-printable characters in the sender,
> one of the recipient addresses, or delay reason, and I process the
> output of "postqueue -j" in a language that supports JSON ("jq",
> "python", "perl", ...) then it should be possible to see the actual
> data without sanitisation.
Then we can ad a -R option that disables filtering (make then do
something extra) with a warning. Will this be necessary for Postfix
3.7? Probably, so that we don't have too much difference between
examples of how to do things.
The threat model is that an attacker can compromise a process with
user "postfix" privileges and subvert the showq daemon or the content
of queue files. The showq daemon is supposed to ignore bogus queue
IDs, bogus queue names, and non-files.
Or, that some well-meaning moron changes Postfix to preserve newlines
in, for example, responses from remote SMTP servers.
Either way, that would subvert text-based postqueue|whatever|postsuper
pipelines that typically run as root.
Wietse
