This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: O_EXEC and O_SEARCH

From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
To: Rich Felker <dalias at aerifal dot cx>
Cc: libc-alpha <libc-alpha at sourceware dot org>, musl at lists dot openwall dot com
Date: Sat, 23 Feb 2013 00:28:00 -0500
Subject: Re: O_EXEC and O_SEARCH
References: <20130222004540.GA8836@brightrain.aerifal.cx> <CAHGf_=p1XsUTR2MfffTTR6dGHRN5f44WFWCRvLoaz9VJyCT2DA@mail.gmail.com><20130223050323.GW20323@brightrain.aerifal.cx> <CAHGf_=p72+wjc_2L4=CQ-qZqt8utPKPqbg=PMOkE2rokDOxrUw@mail.gmail.com>

>>> And, as far as I observed, current linux man pages don't tell us
>>> O_PATH|O_NOFOLLOW
>>> behavior. Is this really intentional result? How do you confirmed?
>>
>> Yes, it seems intentional. O_PATH without O_NOFOLLOW would resolve the
>> symbolic link and open a file descriptor referring to the target
>> inode. O_PATH|O_NOFOLLOW opens a file descriptor to the symbolic link
>> inode itself. As far as I can see, this behavior is desirable and
>> intentional with O_PATH but wrong for O_SEARCH or O_EXEC.
>
> Hmm... Why?
> It doesn't match linux man nor posix.

So, I suggest to don't guess and discuss in LKML directly instead.

References:
- O_EXEC and O_SEARCH
  - From: Rich Felker
- Re: O_EXEC and O_SEARCH
  - From: KOSAKI Motohiro
- Re: O_EXEC and O_SEARCH
  - From: Rich Felker
- Re: O_EXEC and O_SEARCH
  - From: KOSAKI Motohiro

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]