Re: [PATCH] docs: Makefile: Add -no-shell-escape option to LATEXOPTS

[Jonathan Corbet]

Akira Yokosawa <akiyks@xxxxxxxxx> writes:

> By adding this option, message of "restricted \write18 enabled" from
> LaTeX can be silenced.
>
> As there is no use of \write18 in LaTeX sources from sphinx-build, it
> is safe to add this option.
>
> Reported-by: Jonathan Corbet <corbet@xxxxxxx>
> Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
> ---
>  Documentation/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 9f4bd42cef18..64d44c1ecad3 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -26,7 +26,7 @@ SPHINX_CONF   = conf.py
>  PAPER         =
>  BUILDDIR      = $(obj)/output
>  PDFLATEX      = xelatex
> -LATEXOPTS     = -interaction=batchmode
> +LATEXOPTS     = -interaction=batchmode -no-shell-escape

Interesting.  In my digging now and back in 2016 [1] everything I found
said that \write18 had to be explicitly enabled - and for good reason.
And I could never figure out *how* we were enabling it...  It turns out
that the net misinformed me; how come nobody ever told me that could
happen? :)

Anyway, I've applied this, but I'm going to tweak the changelog a bit.
My reason for wanting this isn't to make the warning go away - it's a
*tiny* piece of the noise of a pdfdocs build.  That warning is there for
a reason; \write18 is dangerous.  We really don't want any way for
arbitrary shell commands to be executed via the docs build.  So the new
text is:

  It turns out that LaTeX enables \write18, which allows arbitrary shell
  commands to be executed from the document source, by default.  This the
  often-seen warning during a pdfdocs build:

    restricted \write18 enabled

  That is a potential security problem and is entirely unnecessary; nothing
  in the kernel PDF docs build needs that capability.  So disable \write18
  explicitly.

I think I'll add a Cc: stable while I'm at it.  I know of no actual
threat, but this is best closed.

Thanks for fixing this,

jon

[1] https://lore.kernel.org/lkml/20161113125250.779df4dd@xxxxxxx/