Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752892AbaJYVWZ (ORCPT ); Sat, 25 Oct 2014 17:22:25 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:56846 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752204AbaJYVWX (ORCPT ); Sat, 25 Oct 2014 17:22:23 -0400 Date: Sat, 25 Oct 2014 23:22:21 +0200 From: Pavel Machek To: Andy Lutomirski Cc: Al Viro , David Drysdale , "Eric W. Biederman" , Meredydd Luff , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Morton , Kees Cook , Arnd Bergmann , X86 ML , linux-arch , Linux API Subject: Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call Message-ID: <20141025212220.GA24664@amd> References: <1401975635-6162-1-git-send-email-drysdale@google.com> <20141019202034.GH7996@ZenIV.linux.org.uk> <20141019212921.GI7996@ZenIV.linux.org.uk> <20141019224251.GJ7996@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > >> Oh, you mean that #!/usr/bin/make -f would turn into /usr/bin/make > >> /dev/fd/3? That could be interesting, although I can imagine it > >> breaking things, especially if /dev/fd/3 isn't set up like that, e.g. > >> early in boot. > > > > Sigh... What I mean is that fexecve(fd, ...) would have to put _something_ > > into argv when it execs the interpreter of #! file. Simply because the > > interpreter (which can be anything whatsoever) has no fscking idea what > > to do with some descriptor it has before execve(). Hell, it doesn't have > > any idea *which* descriptor had it been. > > > > You need to put some pathname that would yield your script upon open(2). > > If you bothered to read those patches, you'd see that they do supply > > one, generating it with d_path(). Which isn't particulary reliable. > > > > I'm not sure there's any point putting any of that in the kernel - if > > you *do* have that pathname, you can just pass it. > > Hmm. > > This issue certainly makes fexecve or execveat less attractive, at > least in cases where d_path won't work. > > On the other hand, if you want to run a static binary on a cloexec fd > (or, for that matter, a dynamic binary if you trust the interpreter to > close the extra copy of the fd it gets) in a namespace or chroot where > the binary is invisible, then you need kernel help. > > It's too bad that script interpreters don't have a mechanism to open > their scripts by fd. Every interpretter depends on /dev/zero... so what about having /dev/script_im_running? Standard character device, contains whatever script it should contain... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/