On Mon, Jan 31, 2022 at 05:14:15PM +0100, Christian Brauner wrote:
On Mon, Jan 31, 2022 at 03:51:21PM +0000, Matthew Wilcox wrote:
On Mon, Jan 31, 2022 at 04:37:07PM +0100, Christian Brauner wrote:
On Mon, Jan 31, 2022 at 03:19:22PM +0000, Matthew Wilcox wrote:
On Mon, Jan 31, 2022 at 04:08:19PM +0100, Christian Brauner wrote:
On Mon, Jan 31, 2022 at 10:43:52PM +0800, kernel test robot wrote: I can fix this rather simply in our upstream fstests with:
static char *argv[] = { "", };
I guess.
But doesn't
static char *argv[] = { NULL, };
seem something that should work especially with execveat()?
The problem is that the exec'ed program sees an argc of 0, which is the problem we're trying to work around in the kernel (instead of leaving it to ld.so to fix for suid programs).
Ok, just seems a bit more intuitive for path-based exec than for fd-based execveat().
What's argv[0] supposed to contain in these cases?
- execveat(fd, NULL, ..., AT_EMPTY_PATH)
- execveat(fd, "my-file", ..., )
"" in both 1. and 2.? "" in 1. and "my-file" in 2.?
You didn't specify argv for either of those, so I have no idea. Programs shouldn't be assuming anything about argv[0]; it's purely advisory. Unfortunately, some of them do. And some of them are suid.
Yes, programs shouldn't assume anything about argv[0]. But a lot of programs are used to setting argv[0] to the name of the executed binary. The exec* manpages examples do this. Just looking at a random selftest, e.g.
bpf/prog_tests/test_lsm.c
where we find:
char *CMD_ARGS[] = {"true", NULL}; execvp(CMD_ARGS[0], CMD_ARGS);
I'm just wondering how common this is for execveat() because it is not as clear what the actual name of the binary is in these two examples
fd = open("/bin/true", ); char *CMD_ARGS[] = {"", NULL}; execveat(fd, NULL, ..., AT_EMPTY_PATH) 2. fd = open("/bin", ); char *CMD_ARGS[] = {"true", NULL}; execveat(fd, CMD_ARGS[0], CMD_ARGS 0)
in other words, the changes that you see CMD_ARGS[0] == NULL for execveat() seem higher than for path-based exec.
To counter that we should probably at least update the execveat() manpage with a recommendation what CMD_ARGS[0] should be set to if it isn't allowed to be set to NULL anymore. This is why was asking what argv[0] is supposed to be if the binary doesn't take any arguments.
Sent a fix to our fstests now replacing the argv[0] as NULL with "".