Demi Marie Obenour writes: > On 11/2/25 07:43, Alyssa Ross wrote: >> On Sun, Nov 02, 2025 at 01:18:02PM +0100, Alyssa Ross wrote: >>> Demi Marie Obenour writes: >>> >>>> On 11/1/25 08:17, Alyssa Ross wrote: >>>>> Demi Marie Obenour writes: >>>>> >>>>>> On 10/29/25 08:01, Alyssa Ross wrote: >>>>>>> Demi Marie Obenour writes: >>>>>>> >>>>>>>> Spectrum OS's host has no network access. Updates must be downloaded by >>>>>>>> VMs. The downloads are placed into a bind-mounted directory. The VM >>>>>>>> can write whatever it wants into that directory. This includes symlinks >>>>>>>> that subsequent code might open, which would create a path traversal >>>>>>>> vulnerability. It also includes paths with names containing containing >>>>>>>> terminal escape sequences, newlines, or other nastiness. Furthermore, >>>>>>>> the directory should not have any subdirectories either. >>>>>>>> >>>>>>>> Add a simple C program that checks for such ugliness and indicates >>>>>>>> (via its exit code) if the VM misbehaved. It also ensures that both >>>>>>>> SHA256SUMS and SHA256SUMS.gpg are present. >>>>>>>> >>>>>>>> Signed-off-by: Demi Marie Obenour >>>>>>>> --- >>>>>>>> host/rootfs/Makefile | 6 +- >>>>>>>> lib/kcmdline-utils.mk | 6 ++ >>>>>>>> tools/default.nix | 1 + >>>>>>>> tools/meson.build | 1 + >>>>>>>> tools/updates-dir-check/meson.build | 4 ++ >>>>>>>> tools/updates-dir-check/updates-dir-check.c | 94 +++++++++++++++++++++++++++++ >>>>>>>> 6 files changed, 110 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> I still don't really understand why this needs to be a C program instead >>>>>>> of find -H /path/to/dir -not -type f. None of the other checks seem >>>>>>> very necessary? >>>>>> >>>>>> I trust this code more than I trust (especially) the Busybox >>>>>> implementation of find. >>>>> >>>>> This doesn't really make sense to me. All of this is quite trivial find >>>>> behaviour — not the sort of thing that's unlikely to have been widely >>>>> tested. No objection to GNU find though if it helps. >>>> >>>> I see: find with a -exec false to return an error if anything matching >>>> is found? >>>> >>>> I'm way more familiar with C than with find, which is why I missed this. >>> >>> Hmm, thinking about it some more I suppose there's a problem with find: >>> there's no way to get it to exit as soon as it finds a matching file, >>> with a failing error code, so it could end up running way too long. >>> >>> So the C program is fine, I guess. >> >> Actually, we can do it. We just need to make find not responsible for >> exiting. >> >> foreground { >> pipeline { find -H /path/to/dir -mindepth 1 -not -type f -prune } >> grep -q . >> } >> importas -iu ? ? >> if { test $? -eq 1 } >> # We have only regular files. >> >> When find prints a line, grep will exit, and find will receive SIGPIPE >> and exit. > > This version also has a bug: if find exits with an error without > printing anything, the exit status will be ignored. Something like > this (not tested) might work: > > pipeline { find -H /path/to/dir -mindepth 1 -not -type f -prune } > importas -iu ! ! > foreground { grep -q . } > if { importas -iu ? ? test $? -eq 1 } > wait $! > importas -iu ? ? > if { test $? -eq 0 } > > However, it's all way way way way too subtle for me. It's short, > but it's also extremely error-prone. The C program is longer, but > it's also much easier to understand and modify. Okay. :)