Restricting path name lookup with openat2()

Posted Aug 24, 2019 5:28 UTC (Sat) by cyphar (subscriber, #110703)
In reply to: Restricting path name lookup with openat2() by k8to
Parent article: Restricting path name lookup with openat2()

Yes, it is checked (you get -EINVAL if it's non-zero).

As for figuring out whether syscalls have particular features, the best way is to pass the flag and see if you get -EINVAL -- this is why checking whether there are unknown flags present and returning -EINVAL is important in syscall design. If you don't check whether unknown flags are passed, you end up with situations where userspace cannot easily figure out whether the flag is actually supported. open(2) doesn't do this check (which makes it significantly more complicated to figure out whether your kernel supports a particular open(2) feature), but in openat2(2) we do check whether there are unknown O_* flags present.

Restricting path name lookup with openat2()

Posted Aug 24, 2019 20:14 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (1 responses)

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.

Restricting path name lookup with openat2()

Posted Aug 26, 2019 19:18 UTC (Mon) by k8to (guest, #15413) [Link]

Thanks. That makes sense. Probably the manpage will tell me to do just that, and I would have figured it out upon reading it.