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. -- Sincerely, Demi Marie Obenour (she/her/hers)