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.
