Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbaJ0SBf (ORCPT ); Mon, 27 Oct 2014 14:01:35 -0400 Received: from mail-qa0-f44.google.com ([209.85.216.44]:33966 "EHLO mail-qa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752412AbaJ0SBc (ORCPT ); Mon, 27 Oct 2014 14:01:32 -0400 MIME-Version: 1.0 In-Reply-To: <87wq7shuk6.fsf@x220.int.ebiederm.org> References: <1401975635-6162-1-git-send-email-drysdale@google.com> <87zjcszz8y.fsf@x220.int.ebiederm.org> <87ioje2ggq.fsf@x220.int.ebiederm.org> <87wq7shuk6.fsf@x220.int.ebiederm.org> From: David Drysdale Date: Mon, 27 Oct 2014 18:01:10 +0000 Message-ID: Subject: Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call To: "Eric W. Biederman" Cc: Andy Lutomirski , Alexander Viro , 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 22, 2014 at 6:40 PM, Eric W. Biederman wrote: > David Drysdale writes: >> On Tue, Oct 21, 2014 at 5:29 AM, Eric W. Biederman >> wrote: >>> It is more a description of what we have done but as a magic string it >>> is descriptive. Documetation/devices.txt documents that /dev/fd/ should >>> exist, making it an unambiguous path. Further these days the kernel >>> sets the device naming policy in dev, so I think we are strongly safe in >>> using that path in any event. >>> >>> I think execveat is interesting in the kernel because the motivating >>> cases are the cases where anything except a static executable is >>> uninteresting. >> >> FYI, there is potential in the future for something other than static >> executables -- the FreeBSD Capsicum implementation includes changes >> to the dynamic linker to get its search path as a list of pre-opened dfds >> (in LD_LIBRARY_PATH_FDS) rather than paths. > > Which still leaves open the question how do you find the dynamic > linker. Is that also a pre-opened dfd? I *think* it's still effectively a path lookup of the INTERP header in the kernel (but the pathname is restricted to be one of a set of standard pre-registered interpreters). > Using /dev/fd/$N is also the kind of thing that a shell or a script > interpret could special case instead relying on a filesystem node > to exist. True. -- 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/