Re: [PATCH 3/7] tools: Add directory checker for updates

Alyssa Ross
2025-11-02T12:43:18Z

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

On Sun, Nov 02, 2025 at 01:18:02PM +0100, Alyssa Ross wrote:
> Demi Marie Obenour <demiobenour@gmail.com> writes:
>
> > On 11/1/25 08:17, Alyssa Ross wrote:
> >> Demi Marie Obenour <demiobenour@gmail.com> writes:
> >>
> >>> On 10/29/25 08:01, Alyssa Ross wrote:
> >>>> Demi Marie Obenour <demiobenour@gmail.com> 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 <demiobenour@gmail.com>
> >>>>> ---
> >>>>> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]