[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [PATCH] fcntl-h: default O_SEARCH, O_EXEC to O_PATH if available
Date: Mon, 05 Nov 2012 14:24:39 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]