execveat() was added to Linux in kernel 3.19:
http://man7.org/linux/man-pages/man2/execveat.2.html

It may be interesting to expose it in Python.

"The primary aim of adding an execveat syscall is to allow an
implementation of fexecve(3) that does not rely on the /proc
filesystem.  The current glibc version of fexecve(3) is implemented
via /proc, which causes problems in sandboxed or otherwise restricted
environments."
http://lwn.net/Articles/600344/

I'm not more interested to work on this issue, so I just close it. I'm not convinced that there is a real need for it in Python, and it's not obvious how it should be exposed.

Open a new issue or reopen this issue if you want to work the issue.

It is actual to me due to it's AT_EMPTY_PATH feature (I download script, verify signature, and want to run it)

See also `man 3 fexecve`

Why not to add `dir_fd=None` ?  (as in `os.rmdir()` for example).

It should be very small patch, as I think.

Reopen please.

You can currently call os.execve with a file pointer.  How is that different from adding an execveat with AS_EMPTY_PATH, functionally?  I think we don't need to add this syscall, because it is intended to allow more robust implementation of fexecve, and we are already effectvely exposing fexecve.  We should be able to assume that glibc will switch to using execveat under the hood, and not worry about it ourselves.  If that's not true, then we can revisit this.

> we are already effectvely exposing fexecve

Did not found neither os.fexecve() nor os.execve() documentation about this. How I can use glibc's fexecve() ?

By passing an fd to os.execve.  Under the hood it calls fexecve.

Sorry, but still did not found that in official documentation. Pass fd in place of `path ` ?

https://docs.python.org/3.6/library/os.html#os.execve

Yes, last paragraph of that section.  It doesn't mention fexecve explicitly because it doesn't need to, the functionality is what matters.