On Mon 17 Jul 2023 01:10:17 GMT, Zefram wrote: > Package: moreutils > Version: 0.65-1 > Severity: normal > > ts(1) is documented to take a `format' argument on its command line, > and no other non-option arguments. In fact, if given more arguments then > it won't complain about a usage error, but then won't read its standard > input, and will do more or less bizarre things with the extra arguments. > On the mild end of the spectrum, sometimes it will use an argument as > a filename, and take input from that file (which is pointless for a > regular file): > > $ echo a > t0 > $ ts %F t0 > 2023-07-17 a > $ > > It gets weirder if an argument contains certain characters that are not > usually used in filenames: > > $ ls -l > total 4 > -rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0 > $ ts %F '>t1' > $ ls -l > total 4 > -rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0 > -rw-rw-r-- 1 zefram zefram 0 Jul 17 00:49 t1 > $ echo c > 't2 ' > $ ts %F 't2 ' > Can't open t2 : No such file or directory at /usr/bin/ts line 113. > $ ts %F '|echo wibble' > wibble > $ > > The details of this behaviour arise because, after failing to check > for extraneous arguments, the program uses the <> Perl operator, > which magically implements a variety of interpretations of command line > arguments. The range of behaviour includes writing to arbitrary files > and running arbitrary commands, which are very undesirable behaviours > for ts(1). However, the seriousness of the problem is limited by the > fact that this behaviour only arises if the program is invoked with > extraneous arguments, contrary to its documentation. > > It might be considered desirable for ts(1) to read input from files > named on the command line. (Though pointless for regular files.) > If that is the case then it would not be wrong for the program to > accept the additional arguments. But in that case it would still be > wrong for it to use the <> Perl operator, which is not suitable for the > implementation of a read-from-list-of-files kind of command, because > of the variety of behaviour described above. It would also make this > a more serious bug, because the dangerous behaviour such as writing to > files could be invoked by attempts to read from files. It would also be > a documentation bug that the possibility of naming files on the command > line was not mentioned in the man page or usage message.
thanks for the very detailed bug description and reasoning, I really
appreciate it! As the documentation does not mention anything about
reading input from files, I think, reading STDIN explicitly is probably
the best.
Would this patch be sufficiently safe?
diff --git a/ts b/ts
index af23cf7..b39a395 100755
--- a/ts
+++ b/ts
@@ -112,3 +112,3 @@ else {
-while (<>) {
+while (<STDIN>) {
if (! $rel) {
If it is, I would like to include your reasoning into a patch for
upstream, ok?
Kind regards,
Nicolas
--
epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
signature.asc
Description: PGP signature
