Re: [PATCHv5 1/3] syscalls,x86: implement execveat() system call
flat view
From: Andy Lutomirski <hidden>
Date: 2014-10-22 18:44:53
Also in:
linux-arch, lkml
On Wed, Oct 22, 2014 at 4:44 AM, David Drysdale [off-list ref] wrote:
Add a new system execveat(2) syscall. execveat() is to execve() as openat() is to open(): it takes a file descriptor that refers to a directory, and resolves the filename relative to that.
quoted hunk ↗ jump to hunk
bprm->file = file; - bprm->filename = bprm->interp = filename->name; + if (fd == AT_FDCWD || filename->name[0] == '/') { + bprm->filename = filename->name; + } else { + /* + * Build a pathname that reflects how we got to the file, + * either "/dev/fd/<fd>" (for an empty filename) or + * "/dev/fd/<fd>/<filename>". + */ + pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY); + if (!pathbuf) { + retval = -ENOMEM; + goto out_unmark; + } + bprm->filename = pathbuf; + if (filename->name[0] == '\0') + sprintf(pathbuf, "/dev/fd/%d", fd);
If the fd is O_CLOEXEC, then this will result in a confused child process. Should we fail exec attempts like that for non-static programs? (E.g. set filename to "" or something and fix up the binfmt drivers to handle that?)
quoted hunk ↗ jump to hunk
+ else + snprintf(pathbuf, PATH_MAX, + "/dev/fd/%d/%s", fd, filename->name);
Does this need to handle the case where the result exceeds PATH_MAX? --Andy