Restricting path name lookup with openat2()

Posted Aug 23, 2019 6:21 UTC (Fri) by pr1268 (guest, #24648)
Parent article: Restricting path name lookup with openat2()

__u64 reserved[7]; /* must be zeroed */

Why so much empty reserved space? Requiring the use of a struct with 56 empty bytes simply for "reserve" seems unusual.

I'm sure there's a good reason, not just for having the reserve space, but also for having so much of it, but I didn't glean that from the article.

Restricting path name lookup with openat2()

Posted Aug 23, 2019 11:57 UTC (Fri) by cyphar (subscriber, #110703) [Link] (5 responses)

I don't have a particularly strong justification for the size, it was just an arbitrary* (and probably wrong) choice. I don't really mind how we handle the extensibility of open_how, so long as it means we can expand openat2(2) in the future sanely. One other idea I had was a version or size field that would allow for the struct to be resized (rather than taking up a block of space needlessly), but I have a feeling that would be even less acceptable to most people.

* Though, the struct being 64-bytes overall does mean it fits in one cache-line. That's not a good argument for it to be that big, but it does mean that making it any bigger than 64 bytes would be a much worse idea. I figured that I might as well make it as big as reasonable and see what other ideas people came up with.

Restricting path name lookup with openat2()

Posted Aug 23, 2019 22:21 UTC (Fri) by josh (subscriber, #17465) [Link] (2 responses)

You don't need to have a separate size field, just reserve one of the flags in the flags field to indicate future structure growth. Then, some future version that needs to add more data to the structure can set that flag.

Restricting path name lookup with openat2()

Posted Aug 24, 2019 5:54 UTC (Sat) by buck (subscriber, #55985) [Link] (1 responses)

forgive me if this is covered on the kernel developers list or is a common antipattern. (if so, please feel free to dismiss this with an informative link in reply). but why not start the structure with a protocol version number, like network packets (e.g., IP first nibble, kerberos protocol messages' and SNMP PDUs' first integer)? then you pass in whatever struct is appropriate to the protocol version, with its size (a la socklen_t of bind(2)), and the kernel checks the protocol version at the top to figure out which structure it's been passed and how to interpret

Restricting path name lookup with openat2()

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

The size *is* a protocol version number, essentially.

Restricting path name lookup with openat2()

Posted Jan 9, 2021 7:55 UTC (Sat) by Serentty (guest, #132335) [Link] (1 responses)

Why reserve any space at all instead of passing in the size like clone3() does?

Restricting path name lookup with openat2()

Posted Feb 3, 2021 5:50 UTC (Wed) by cyphar (subscriber, #110703) [Link]

clone3 and openat2 use the same design for extension, and Christian and I gave a talk about this design at Linux Plumbers last year. You're commenting on a thread which is almost 2 years old. :P