From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2835 Path: news.gmane.org!not-for-mail From: KOSAKI Motohiro Newsgroups: gmane.linux.lib.musl.general Subject: Re: O_EXEC and O_SEARCH Date: Fri, 22 Feb 2013 22:58:18 -0500 Message-ID: References: <20130222004540.GA8836@brightrain.aerifal.cx> <20130223031708.GU20323@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 1361591931 7308 80.91.229.3 (23 Feb 2013 03:58:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Feb 2013 03:58:51 +0000 (UTC) Cc: libc-alpha , musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-2836-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 23 04:59:11 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 1U96GV-0005aK-BX for gllmg-musl@plane.gmane.org; Sat, 23 Feb 2013 04:59:11 +0100 Original-Received: (qmail 21748 invoked by uid 550); 23 Feb 2013 03:58:50 -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 21739 invoked from network); 23 Feb 2013 03:58:50 -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=8wz+ik+UQggQhxuBVqs78t9QJQlx1dZHWTnsl9HcHQg=; b=xs8Jp3TEqU9fmlXuPsGFE7mS/RET6KJH6VTdglu6e6S+LKmBJ1s4a/X/kFTV/pfTpl JucFqkwLYMptTq5+Kw/Yo1sGKn1nnYFgJ6TDtGoVn1OtFbSZhippF2fmfAFUaQ2kIp1/ HyICvdUM/naXvGk3JWTdhsrGVUbGRAS34SmAiyIphKYQ+Blsf/DK8nai41MIQrZFkoLy obsqXrcipS2ao5rUTxIonD9v5ppsYMdwq28h7MdGBlZ4jLjTC96WzcOQxfT39ffZqT9T YNy+A8ktQIzTCD3khM5mqdH1IjKo941vFOAtHlUJOjJTcjoE/aCGt7ADttc0YxBj8gfp zLWA== X-Received: by 10.182.52.102 with SMTP id s6mr1711394obo.87.1361591918576; Fri, 22 Feb 2013 19:58:38 -0800 (PST) In-Reply-To: <20130223031708.GU20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2835 Archived-At: On Fri, Feb 22, 2013 at 10:17 PM, Rich Felker wrote: > On Fri, Feb 22, 2013 at 10:05:03PM -0500, KOSAKI Motohiro wrote: >> > I'd like to have a conversation with the glibc team about O_EXEC and >> > O_SEARCH in the interest of hopefully developing a unified plan for >> > supporting them on Linux. Presumably the reason glibc still does not >> > have them is that Linux O_PATH does not exactly match their semantics >> > in some cases, and O_PATH is sufficiently broken on many kernel >> > versions to make offering it problematic. In particular, current >> > coreutils break badly on most kernel versions around 2.6.39-3.6 or so >> > if O_SEARCH and O_EXEC are defined as O_PATH. >> >> I'm curious why don't you implement them in kernel directly? > > See this thread for Linus's opinion on why O_SEARCH was not added: > > http://comments.gmane.org/gmane.linux.file-systems/33611 > > O_NODE seems to have been renamed to O_PATH, or perhaps O_PATH was a > later independent implementation of the same idea; it's not clear to > me which happened. But the idea is that the kernel folks did not want > to do O_SEARCH and O_EXEC properly in kernelspace but instead wanted > to provide a more general flag that could be used to implement both > O_SEARCH and O_EXEC. Do you mean following response? >I suspect that what we _could_ possibly do is to have something like >O_NODE, and after that - if the semantics (for directories) match what >O_SEARCH/O_EXEC wants, we could just do > >#define O_SEARCH O_NODE > >but my point is that we should _not_ start from O_SEARCH and make that the >"core" part, since its semantics are badly defined (undefined) to begin >with. I so, I don't think "start" mean refusing at all. However, I agree kernel folks dislike to hear "because it's posix". As far as no concrete good use case, any proposal may be going to be get negative response. However, if O_SEARCH is really useful, I think in kernel implementation is better because all other flags are implemented in kernel and it may prevent to create ugly corner case.