Re: [PATCH] fcntl-h: default O_SEARCH, O_EXEC to O_PATH if available

[Paul Eggert]

On 11/05/2012 02:02 PM, Eric Blake wrote:

> Do we really want the ability to open a symlink as an fd
> when using O_EXEC permissions, instead of following the
> symlink into the file that it normally points to?

Opening the symlink with open ("symlink", O_EXEC) should be
OK, since it will follow the symlink.

So I assume you're talking about opening a symlink with
open ("symlink", O_EXEC|O_NOFOLLOW).  This now succeeds,
where it formerly failed as POSIX requires.  So in this
sense, defining O_EXEC to O_PATH has a problem -- it's not a
perfect emulation of O_EXEC.  But the same is true for
defining O_EXEC to O_RDONLY.  So the question is whether
falling back to O_PATH is better, overall, than falling back
to O_RDONLY is.  My impression is that O_PATH is a better
fallback for most GNU applications, but it's quite possible
that I'm missing something.

Another possibility would be to redefine 'open' and/or
'openat' so that they reject any attempt to open a symlink
as an fd, when the user specified O_EXEC and/or O_SEARCH.
I.e., Gnulib defines O_EXEC to some value other than O_PATH,
and implements O_EXEC as O_PATH-with-some-extra-checks.
That should do an even better job of emulation, but it'd
take more work.