On Wed, Oct 22, 2014 at 6:40 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > David Drysdale <drysdale@xxxxxxxxxx> writes: >> On Tue, Oct 21, 2014 at 5:29 AM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
