[RFC PATCH 1/1] io: Add FORTIFY_SOURCE check for fcntl arguments

[Sergey Bugaev]

Hello,

On Tue, May 23, 2023 at 10:15 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> *_chk but I don't want to block this good work on that.  The overall
> direction is good IMO

Yay, thanks!

> - manual/contrib.texi should be updated to mention fcntl

Do you mean manual/maint.texi? manual/contrib.texi seems to contain a
list of contributors.

> - Internal users end up calling __libc_fcntl (see dup2.c or grantpt.c
> for example), which will essentially bypass any fortification.  This is
> not a problem today since we don't build glibc with fortification, but
> Frederic Berat[1] has been experimenting with that and we're hoping to
> get at least a subset of glibc fortified for 2.38.  It would be a shame
> to miss fortifying glibc itself.  This is again not a problem that would
> block this patch, but something to be aware of.

Yes, I've thought of this, but I don't know what I could change in
this patch to make it friendlier to in-glibc fortification. I've
generally done things the same way as the open* fortification does; so
I don't think this would be adding any new complications compared to
what's already in there.

> Given that this will error out at compile time, do we even need this
> __fcntl64_2 call?

Same as for the open* fortification: this call will only fail at
compile time if the cmd is a compile-time constant. If it's not (which
is a rare, but valid case), we need to do the check at runtime. Note
that if cmd _is_ a compile-time constant and does not require the 3rd
arg, this will call the regular fcntl, not the _2 version; the _2
version is only for non-compile-time-const cmd-s.

Sergey