From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6546 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general,gmane.linux.kernel.api Subject: Re: [musl] Re: [RFC] Possible new execveat(2) Linux syscall Date: Mon, 17 Nov 2014 13:30:10 -0500 Message-ID: <20141117183010.GE22465@brightrain.aerifal.cx> References: <20141116195246.GX22465@brightrain.aerifal.cx> <20141116220859.GY22465@brightrain.aerifal.cx> <20141116233202.GA22465@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416249027 13890 80.91.229.3 (17 Nov 2014 18:30:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 18:30:27 +0000 (UTC) Cc: Andy Lutomirski , libc-alpha , musl@lists.openwall.com, Andrew Morton , Linux API , Christoph Hellwig To: David Drysdale Original-X-From: libc-alpha-return-54435-glibc-alpha=m.gmane.org@sourceware.org Mon Nov 17 19:30:22 2014 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqR4A-0003Zt-1Z for glibc-alpha@plane.gmane.org; Mon, 17 Nov 2014 19:30:22 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=kG98 sXxaVee2cQLW7qMDtbEOJgCntHfDF4Ry1tvY3k+eJbXzqLKKLTrdXJUSi0H3cBAD Hr58ZYqbNPDBAplzJ0ihRrv74Q4jThjX6hV0FxVIMlA+fzRn/AznXvT/AkTLBGQu Vt0exvLEPJEQSobzRFs5mxlCHvylrOpHSM/pIr8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=/zkafWTRAV mji+224/wE+CLI5AI=; b=bfEEQv+xSZ/H1ymZ6+HOWW3/YlV9Ha3UuaK2iWC7sP ATi0Z47JQbz+7QY+mgb4P6j9WYF40io5+zJmi5jIQE/TDHOi9uR3hxonUhyCjQ0T K8KPiUZ+NbYfWleo6UdXyb7fjP/hWl2AemDEJZj7eSjX2rsNIia5gj7KLVDKs25A A= Original-Received: (qmail 10238 invoked by alias); 17 Nov 2014 18:30:17 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 10223 invoked by uid 89); 17 Nov 2014 18:30:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.comp.lib.glibc.alpha:46731 gmane.linux.lib.musl.general:6546 gmane.linux.kernel.api:6176 Archived-At: On Mon, Nov 17, 2014 at 03:42:15PM +0000, David Drysdale wrote: > I'm not familiar with O_EXEC either, I'm afraid, so to be clear -- does > O_EXEC mean the permission check is explicitly skipped later, at execute > time? In other words, if you open(O_EXEC) an executable then remove the > execute bit from the file, does a subsequent fexecve() still work? Yes. It's just like how read and write permissions work. If you open a file for read then remove read permissions, or open it for write then remove write permissions, the existing permissions to the open file are not lost. Of course open with O_EXEC/O_SEARCH needs to fail if the caller does not have +x access to the file/directory at the time of open. > If it does, then from an implementation perspective that presumably implies > the need for a record of the permission check in the struct file (and that > this property would be inherited by any dup()ed file descriptors). From a > security perspective, having a gap between time-of-check and time-of-use > always sounds worrying... This record already exists for read and write. All that's needed is for an extra bit to be added to record exec/search permission. Rich