System queries with Lua: l3sys-query

[Nicola Talbot]

On 08/03/2024 00:07, David Carlisle wrote:> as far as I can see 
texosquery can't list the current directory if
> openin_any is p
> as it won't accept .  that is more restrictive than \input which lets you
> always \input ./foo.tex
> . isn't a "dotfile" in that sense.

It's not the dot that's the problem if you try a directory listing of 
"." with openin_any=p with texosquery. Paths are converted to their 
canonical form before determining whether access is allowed (which is 
why the symlink in the previous example was skipped). Even if you 
substitute "." with the full path, texosquery won't allow a directory 
listing of the current directory.

$ kpsewhich --var-value=openin_any
p
$ cd
$ mkdir tmp
$ cd tmp
$ touch foo
$ ls -a
.  ..  foo
$ texosquery-jre8 -i , .

$ texosquery-jre8 -i , /home/nlct/tmp

$ texosquery-jre8 -p /home/nlct/tmp

$ texosquery -p ./foo
\fslh home\fslh nlct\fslh tmp\fslh foo

The reason is that texosquery doesn't consider the current directory to 
be within the current directory. However, texosquery is more restrictive 
than TeX in that it doesn't allow a special case for ".tex". I can't see 
any reason for querying file information about that, and it seems a bit 
of a trapdoor to allow it in the current directory where it may be 
unnoticed.

My view is that if a user has gone out of their way to set openin_any to 
the paranoid setting, then they probably have a paranoid view about 
their safety, in which case they might not want the restricted mode to 
be able to find all their files.

You may remember that I demonstrated two malicious packages that if 
simply loaded in the document with \usepackage they would trash all 
document source files (within the limit of openout_any). Allowing a full 
listing of all files in the current directory would extend that scope to 
trashing all files (with write access) in the current directory. Those 
packages were a proof of concept (one used the shell escape in 
restricted mode, the other used TeX's native I/O with the shell escape 
disabled). I'm not aware of any malicious packages that are publicly 
available, but that doesn't mean they won't occur (which is surely the 
reason for TeX's security settings).

Regards
Nicola