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

Alyssa Ross
2025-11-04T15:27:06Z

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

Demi Marie Obenour <demiobenour@gmail.com> 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 <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.

Okay. :)

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