From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2837
Path: news.gmane.org!not-for-mail
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: O_EXEC and O_SEARCH
Date: Fri, 22 Feb 2013 23:54:17 -0500
Message-ID: <CAHGf_=p1XsUTR2MfffTTR6dGHRN5f44WFWCRvLoaz9VJyCT2DA@mail.gmail.com>
References: <20130222004540.GA8836@brightrain.aerifal.cx>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: ger.gmane.org 1361595289 30416 80.91.229.3 (23 Feb 2013 04:54:49 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sat, 23 Feb 2013 04:54:49 +0000 (UTC)
Cc: libc-alpha <libc-alpha@sourceware.org>, musl@lists.openwall.com
To: Rich Felker <dalias@aerifal.cx>
Original-X-From: musl-return-2838-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 23 05:55:11 2013
Return-path: <musl-return-2838-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-2838-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1U978g-0008BG-9c
	for gllmg-musl@plane.gmane.org; Sat, 23 Feb 2013 05:55:10 +0100
Original-Received: (qmail 13610 invoked by uid 550); 23 Feb 2013 04:54:49 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 13602 invoked from network); 23 Feb 2013 04:54:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:mime-version:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type;
        bh=rDvSIdS/1urnt7UR8BzmNL7HqZaeg/0rfsgXO4mQ6is=;
        b=uwKERmedNRI5oCzxcvk1Difo9PT5uLonWqmeSLRwbKtNDN84zkXX4miLIwO5iNbrGu
         nUmeqmyRaooCkmjW1OuE5aQ8nzU0It/cp8J+iwUGi9m6xWiR2yIU6hYpmlxPrP1AAgmt
         J3lx2X23nYTXXyOnDTeSqk0/52xU67OAqGva9CUaLGsuZBpy0opyRpJkKmGrmO+xKLnR
         OoQ7CobU0AsALmI2xgC7Q21JlCeR507wdz9BPF0hj9X/l87GzSO/bq4Sw1fQuk7zSO78
         iu4JHmdmvO3GRdBzV+x4rzUidCHDUjCkTacx5n9EbHtRvRVXd0LzCCQXvbY9eCH+kkm1
         OAzw==
X-Received: by 10.182.23.101 with SMTP id l5mr1755656obf.16.1361595277453;
 Fri, 22 Feb 2013 20:54:37 -0800 (PST)
In-Reply-To: <20130222004540.GA8836@brightrain.aerifal.cx>
Xref: news.gmane.org gmane.linux.lib.musl.general:2837
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/2837>

> Right now, we're offering O_EXEC and O_SEARCH in musl libc, defining
> them as O_PATH. As long as recent Linux is used, this gives nearly
> correct semantics, except that combined with O_NOFOLLOW they do not
> fail when the final component is a symbolic link. I believe it's
> possible to work around this issue on sufficiently modern kernels
> where fstat works on O_PATH file descriptors, but adding the
> workaround whenever O_PATH|O_NOFOLLOW is in the flags would change the
> semantics when O_PATH is used by the caller rather than O_EXEC or
> O_SEARCH, since the value is equal. I'm not sure this is desirable.

I have one more question. If I understand correctly, O_NOFOLLOW is
unspecified in
POSIX. Why do you think the current behavior is not correct?

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?
I mean the current behavior is not natural to me and I doubt it is not
intentional one.