Thread (2 messages) flat view 2 messages, 2 authors, 2014-10-27

Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call

From: David Drysdale <hidden>
Date: 2014-10-27 18:01:35
Also in: linux-arch, lkml

On Wed, Oct 22, 2014 at 6:40 PM, Eric W. Biederman
[off-list ref] wrote:
David Drysdale [off-list ref] writes:
quoted
On Tue, Oct 21, 2014 at 5:29 AM, Eric W. Biederman
[off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help