[TUHS] Re: shell escapes in utilities

At 2023-08-01T13:38:55+0200, Leah Neukirchen wrote: And the *roffs of course. nroff/troff/groff, with the `sy` (system(3)) and `pi` (popen(3)) requests. pic(1) as well ("sh"). groff has, since version 1.12 in 1999, disabled these features by default; the '-U' ("unsafe") command-line option reënables them. It added some additional unsafe requests for arbitrary stream I/O, `open`, `opena` (open with append), and `pso` (`so` for pipeline output). I recently learned of a limitation in the way AT&T and GNU *roffs, at least, construct the string `sy` passes passes to system(3), which makes certain things impossible. Unfortunately it forecloses useful applications, not any particularly malicious ones. There is a problem with trying to embed true newlines into the arguments of a `sy` request. The C++ function that GNU troff uses to assemble the command string (character by character) _does not recognize C/C++ string literal escape sequences_. This means that you _cannot_ embed "\n" in `sy`'s arguments and have it survive, as a newline character, into the command string passed to the standard C library's system(3) function. ("A\nB" gets encoded as 'A', '\\', 'n', 'B', not 'A', '\n', 'B'.) Unfortunately, this appears to be AT&T troff-compatible behavior. But it means that you _cannot_ portably construct multi-line replacement text for sed's 's' command. (Other sed commands like 'a', 'c', and 'i' will be similarly affected.) See Savannah #64071. AT&T troff obviously wasn't written in C++, so this would appear to be an instance of independent oversight. (Where James Clark had gripes about AT&T troff behavior, he left them in source code comments.) I aim to fix this. If I can write an arbitrary shell command, then I darn well ought to be able to embed an arbitrary sed script in that shell command (without needing a GNU sed extension to embed newlines). Regards, Branden