Problem
gh-write-guard.py keeps a heredoc body fed to a shell, since it is the script that shell runs. Where that body is the last one its line opens, it is read line by line as ordinary commands of the outer text rather than kept whole, so a heredoc opener inside the script strips past the script's own delimiter and swallows the real commands after it. The wait-loop rule then never judges them.
Reproduce (constructed)
Allowed on develop and on the #2112 branch, and piping the same text with echo ran in place of the loop into bash prints ran:
bash <<B
cat <<X
B
while [ ! -f /x ]; do sleep 1; done
X
The same holds with a data heredoc before it on the line, as in cat <<A >/dev/null; bash <<B. The #2112 fix keeps a fed body whole only where a data body follows it on the same line.
Done looks like
The command above is denied, and a self-test row pins it, without denying a script fed to a shell that writes a document through a heredoc of its own.
Found by the local strict review of the #2112 fix (handoff #2123). It is older than that fix.
Problem
gh-write-guard.pykeeps a heredoc body fed to a shell, since it is the script that shell runs. Where that body is the last one its line opens, it is read line by line as ordinary commands of the outer text rather than kept whole, so a heredoc opener inside the script strips past the script's own delimiter and swallows the real commands after it. The wait-loop rule then never judges them.Reproduce (constructed)
Allowed on develop and on the #2112 branch, and piping the same text with
echo ranin place of the loop intobashprintsran:The same holds with a data heredoc before it on the line, as in
cat <<A >/dev/null; bash <<B. The #2112 fix keeps a fed body whole only where a data body follows it on the same line.Done looks like
The command above is denied, and a self-test row pins it, without denying a script fed to a shell that writes a document through a heredoc of its own.
Found by the local strict review of the #2112 fix (handoff #2123). It is older than that fix.