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.