This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Linux: expose the new execveat() syscall
Type: enhancement Stage:
Components: Extension Modules Versions: Python 3.6
Status: closed Resolution: later
Dependencies: Superseder:
Assigned To: Nosy List: r.david.murray, socketpair, vstinner
Priority: normal Keywords:

Created on 2015-02-13 12:32 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (8)
msg235889 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-02-13 12:32
execveat() was added to Linux in kernel 3.19:

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
msg240188 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-04-06 21:36
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.
msg266720 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-05-30 22:12
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.
msg266721 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-30 23:57
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.
msg266734 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-05-31 05:44
> 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() ?
msg266736 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-31 06:03
By passing an fd to os.execve.  Under the hood it calls fexecve.
msg266737 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-05-31 06:08
Sorry, but still did not found that in official documentation. Pass fd in place of `path ` ?
msg266753 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-31 14:55
Yes, last paragraph of that section.  It doesn't mention fexecve explicitly because it doesn't need to, the functionality is what matters.
Date User Action Args
2022-04-11 14:58:12adminsetgithub: 67647
2016-05-31 14:55:05r.david.murraysetmessages: + msg266753
2016-05-31 06:08:43socketpairsetmessages: + msg266737
2016-05-31 06:03:35r.david.murraysetmessages: + msg266736
2016-05-31 05:44:34socketpairsetmessages: + msg266734
2016-05-30 23:57:43r.david.murraysetnosy: + r.david.murray
messages: + msg266721
2016-05-30 22:12:56socketpairsetversions: + Python 3.6, - Python 3.5
nosy: + socketpair

messages: + msg266720

type: enhancement
2015-04-06 21:36:11vstinnersetstatus: open -> closed
resolution: later
messages: + msg240188
2015-02-13 12:32:39vstinnercreate