Hi,
Over at the LKML[1] we've been discussing a possible new syscall, execveat(2),
and it would be good to hear a glibc perspective about it (and whether there
are any interface changes that would make it easier to use from userspace).
The syscall prototype is:
int execveat(int fd, const char *pathname,
char *const argv[], char *const envp[],
int flags); /* AT_EMPTY_PATH, AT_SYMLINK_NOFOLLOW */
and it works similarly to execve(2) except:
- the executable to run is identified by the combination of fd+pathname, like
other *at(2) syscalls
- there's an extra flags field to control behaviour.
(I've attached a text version of the suggested man page below)
One particular benefit of this is that it allows an fexecve(3) implementation
that doesn't rely on /proc being accessible, which is useful for sandboxed
applications. (However, that does only work for non-interpreted programs:
the name passed to a script interpreter is of the form "/dev/fd/<fd>/<path>"
or "/dev/fd/<fd>", so the executed interpreter will normally still need /proc
access to load the script file).
How does this sound from a glibc perspective?
Thanks,
David
[1] https://lkml.org/lkml/2014/11/7/512, with earlier discussions at
https://lkml.org/lkml/2014/11/6/469, https://lkml.org/lkml/2014/10/22/275
and https://lkml.org/lkml/2014/10/17/428
----
EXECVEAT(2) Linux Programmer's Manual EXECVEAT(2)
NAME
execveat - execute program relative to a directory file descriptor
SYNOPSIS
#include <unistd.h>
int execveat(int fd, const char *pathname,
char *const argv[], char *const envp[],
int flags);
DESCRIPTION
The execveat() system call executes the program pointed to by the
combination of fd and pathname. The execveat() system call oper‐
ates in exactly the same way as execve(2), except for the differ‐
ences described in this manual page.
If the pathname given in pathname is relative, then it is inter‐
preted relative to the directory referred to by the file descriptor
fd (rather than relative to the current working directory of the
calling process, as is done by execve(2) for a relative pathname).
If pathname is relative and fd is the special value AT_FDCWD, then
pathname is interpreted relative to the current working directory
of the calling process (like execve(2)).
If pathname is absolute, then fd is ignored.
If pathname is an empty string and the AT_EMPTY_PATH flag is speci‐
fied, then the file descriptor fd specifies the file to be exe‐
cuted.
flags can either be 0, or include the following flags:
AT_EMPTY_PATH
If pathname is an empty string, operate on the file referred
to by fd (which may have been obtained using the open(2)
O_PATH flag).
AT_SYMLINK_NOFOLLOW
If the file identified by fd and a non-NULL pathname is a
symbolic link, then the call fails with the error EINVAL.
RETURN VALUE
On success, execveat() does not return. On error -1 is returned,
and errno is set appropriately.
ERRORS
The same errors that occur for execve(2) can also occur for
execveat(). The following additional errors can occur for
execveat():
EBADF fd is not a valid file descriptor.
ENOENT The program identified by fd and pathname requires the use
of an interpreter program (such as a script starting with
"#!") but the file descriptor fd was opened with the
O_CLOEXEC flag and so the program file is inaccessible to
the launched interpreter.
EINVAL Invalid flag specified in flags.
ENOTDIR
pathname is relative and fd is a file descriptor referring
to a file other than a directory.
VERSIONS
execveat() was added to Linux in kernel 3.???.
NOTES
In addition to the reasons explained in openat(2), the execveat()
system call is also needed to allow fexecve(3) to be implemented on
systems that do not have the /proc filesystem mounted.
SEE ALSO
execve(2), fexecve(3)
Linux 2014-04-02 EXECVEAT(2)
--
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
