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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3643 bytes --]

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 <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.

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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]