bug-gnulib
[Top][All Lists]
Advanced

[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: Eric Blake
Subject: Re: [PATCH] fcntl-h: default O_SEARCH, O_EXEC to O_PATH if available
Date: Mon, 05 Nov 2012 15:02:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

On 11/05/2012 02:56 PM, Paul Eggert wrote:
> Linux kernel 2.6.39 introduced O_PATH (see
> <http://lwn.net/Articles/433854/>) and this is a better fallback
> for O_SEARCH and O_EXEC than O_RDONLY, if O_PATH is available.
> * doc/posix-headers/fcntl.texi (fcntl.h): Document this.
> * lib/fcntl.in.h (O_EXEC, O_SEARCH) [O_PATH]: Default to O_PATH.
> * lib/fcntl.in.h (O_ACCMODE):
> * tests/test-fcntl-h.c (main):
> Do not reject O_ACCMODE merely because it has more than the
> minimal number of bits, as POSIX allows extensions here.
> ---
>  ChangeLog                    | 13 +++++++++++++
>  doc/posix-headers/fcntl.texi |  4 +++-
>  lib/fcntl.in.h               | 14 +++++++++++---
>  tests/test-fcntl-h.c         |  2 +-
>  4 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/ChangeLog b/ChangeLog
> index 2173fb2..3576e7a 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,16 @@
> +2012-11-05  Paul Eggert  <address@hidden>
> +
> +     fcntl-h: default O_SEARCH, O_EXEC to O_PATH if available
> +     Linux kernel 2.6.39 introduced O_PATH (see
> +     <http://lwn.net/Articles/433854/>) and this is a better fallback
> +     for O_SEARCH and O_EXEC than O_RDONLY, if O_PATH is available.

Is that really wise?  According to that page,

"A file opened with this flag will have had its path resolved by the
kernel and is known to exist, but there is little else that can be done
with it. System calls which operate on file descriptors directly
(close() or dup(), for example) will work; these file descriptors can
also be passed to another process over Unix-domain sockets using
SCM_RIGHTS datagrams. The reason for the existence of O_PATH file
descriptors is for use as the directory file descriptor in the various
"*at()" system calls."

"O_PATH flag also allow a descriptor for symlinks. That is the main
difference IMHO."

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?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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