On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote: > On 11/24/2014 12:53 PM, David Drysdale wrote: > > Signed-off-by: David Drysdale <drysdale@xxxxxxxxxx> > > --- > > man2/execveat.2 | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 153 insertions(+) > > create mode 100644 man2/execveat.2 > > David, > > Thanks for the very nicely prepared man page. I've done > a few very light edits, and will release the version below > with the next man-pages release. > > I have one question. In the message accompanying > commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 you wrote: > > The filename fed to the executed program as argv[0] (or the name of the > script fed to a script interpreter) will be of the form "/dev/fd/<fd>" > (for an empty filename) or "/dev/fd/<fd>/<filename>", effectively > reflecting how the executable was found. This does however mean that > execution of a script in a /proc-less environment won't work; also, script > execution via an O_CLOEXEC file descriptor fails (as the file will not be > accessible after exec). > > How does one produce this situation where the execed program sees > argv[0] as a /dev/fd path? (i.e., what would the execveat() > call look like?) I tried to produce this scenario, but could not. I think this is wrong. argv[0] is an arbitrary string provided by the caller and would never be derived from the fd passed. It's AT_EXECFN, /proc/self/exe, and filenames shown elsewhere in /proc that may be derived in odd ways. I would also move the text about O_CLOEXEC to a BUGS or NOTES section rather than the main description. The long-term intent should be that script execution this way should work. IIRC this was discussed earlier in the thread. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
