Restricting path name lookup with openat2()

Posted Aug 24, 2019 20:14 UTC (Sat) by quotemstr (subscriber, #45331)
In reply to: Restricting path name lookup with openat2() by cyphar
Parent article: Restricting path name lookup with openat2()

This check makes a lot of sense when we're talking about *flags*. But why also check reserved fields when any future use of a reserved field could be signaled through the use of a flag? Can you elaborate on what concrete problems checking this reserved field zero check is supposed to address when any new functionality will get a new flag anyway?

Restricting path name lookup with openat2()

Posted Aug 25, 2019 14:51 UTC (Sun) by cyphar (subscriber, #110703) [Link]

It wouldn't be necessary to add a new flag to represent entirely new features if you have a reserved (must be zeroed) block in the struct. As an example, imagine if open_how->resolve wasn't included in this version of the series (and open_how->reserved was one u16 bigger). In a later kernel version we could introduce open_how->resolve as a field and shrink open_how->reserved -- as long as the zero-value had identical semantics there wouldn't be a break in backwards-compatibility and new programs could use the new field (getting -EINVAL if they run on older kernels).

All of that being said, I am gravitating towards not having reserved space. I don't have particularly strong opinions either way.