From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2842 Path: news.gmane.org!not-for-mail From: KOSAKI Motohiro Newsgroups: gmane.linux.lib.musl.general Subject: Re: O_EXEC and O_SEARCH Date: Sat, 23 Feb 2013 00:20:58 -0500 Message-ID: References: <20130222004540.GA8836@brightrain.aerifal.cx> <20130223050323.GW20323@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 1361596898 9179 80.91.229.3 (23 Feb 2013 05:21:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Feb 2013 05:21:38 +0000 (UTC) Cc: libc-alpha , musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-2842-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 23 06:22:00 2013 Return-path: 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 ) id 1U97YW-00046O-5y for gllmg-musl@plane.gmane.org; Sat, 23 Feb 2013 06:21:52 +0100 Original-Received: (qmail 24562 invoked by uid 550); 23 Feb 2013 05:21:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24554 invoked from network); 23 Feb 2013 05:21:31 -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=WpVkvTID4Xt6H/wEO0G8v8AF9FMi9YGMemUIRhSYIww=; b=s/OE2+EVy/hvdH1UMGntiVtbxogj0I+MYoohXTuQG2/4YNgSOXn7SBF0wTQJNIw9v5 ilJzsmcdA+2IMnMhCQKpuX5+OFyiJ0IHueQ0TariyGdgnva9kfKLLccAI7cSvskYzpXd SNdM4Z7blNTOhC7nqq61H+tDEt0zFKumPaRkCyRDS9fVgCKWTxMuE37IVcPeOV29uV9Q E58h+mLxpQ7ayAREJwEcgl8AmrcqgtDMA9rDI0CcAAVk8rTPmLN4L2Zy4cfTSvZ4G41m gEcofgVv6afT+RufGdOdAZUv0ZBeCHmt1HMYuMDNncplEplES0ZojBCnYQx49Jlkrtlv 1JIg== X-Received: by 10.182.183.2 with SMTP id ei2mr1722069obc.84.1361596879305; Fri, 22 Feb 2013 21:21:19 -0800 (PST) In-Reply-To: <20130223050323.GW20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2842 Archived-At: On Sat, Feb 23, 2013 at 12:03 AM, Rich Felker wrote: > On Fri, Feb 22, 2013 at 11:54:17PM -0500, KOSAKI Motohiro wrote: >> > 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. > > Wrong. > >> Why do you think the current behavior is not correct? > > O_NOFOLLOW > If path names a symbolic link, fail and set errno to [ELOOP]. > > See http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html ok. this is linux kernel man pages mistake. http://man7.org/linux/man-pages/man2/open.2.html > O_NOFOLLOW > If pathname is a symbolic link, then the open fails. This is a > FreeBSD extension, which was added to Linux in version 2.1.126. > Symbolic links in earlier components of the pathname will still be > followed. >> 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.