Re: Hurd and trust relationship with file system translators

* Samuel Thibault:

> Hello,
>
> Florian Weimer, le ven. 07 août 2026 18:40:00 +0200, a ecrit:
>> We're sitting on a bunch of Hurd-specific bug reports that concern the
>> interaction with file system translators across trust boundaries.
>
> Thanks for this!
>
>> One specific example (RHEL-216329) is in
>> sysdeps/mach/hurd/readdir64.c, where a comment says:
>> 
>>           /* We trust the filesystem to return correct data and so we
>>              ignore NENTRIES.  */
>> 
>> In contrast, the report claims we have to validate the data because we
>> can't trust the translator:
>> 
>> | Summary: OOB Read in GNU/Hurd `readdir64` / `readdir64_r` due to missing
>> | per-record bounds checks: malformed directory records returned by a
>> | GNU/Hurd filesystem server or translator can be consumed without validating
>> | record boundaries, leading to out-of-bounds reads and likely client-process
>> | crashes.
>> | Requirements to exploit: An attacker must be able to control or influence a
>> | GNU/Hurd filesystem server/translator that returns malformed `dir_readdir`
>> | data, and must cause a target process to enumerate a directory backed by
>> | that service via `opendir()` and `readdir64()` or `readdir64_r()`.
>> 
>> Is this accurate, or is this just a misunderstanding of how translators
>> work and where the trust boundaries are located?
>
> In general, we do trust translators, and we do not plan to let users
> discuss with other users' translators.
>
> Checking for incoherencies can still be useful to report errors rather
> than get odd segfaults.

Thank you for your comments.  So it looks like those aren't security
bugs after all.

I think we've got better-formatted markdown files with those reports
now.  I could post them to this thread in case people want to take a
look?

Thanks,
Florian