Commits on Source (14)
-
We'll want to reuse these inside desktop-shell as well as the Weston frontend. Signed-off-by: Daniel Stone <daniels@collabora.com>
b685e075 -
Make sure that we only try to finalize once. Signed-off-by: Daniel Stone <daniels@collabora.com>
3af823b6 -
Rename the bits handling environment variables (currently, all of it), so we have room to handle args as well. No functional changes. Signed-off-by: Daniel Stone <daniels@collabora.com>
fafe5f0f -
Test the basic stuff: initialising from a known environment, setting a new variable, overwriting a previous variable, and getting the resulting array to pass to execve. Signed-off-by: Daniel Stone <daniels@collabora.com>
2a9cae17 -
execve() takes the same form for arguments as environment: an array of constant pointers to mutable strings, terminated by a NULL. To make it easier for users who want to build up their own argument strings to pass to execve, add support for argument arrays to custom_env. Signed-off-by: Daniel Stone <daniels@collabora.com>
e568a025 -
Users like desktop-shell want to parse a provided string containing a combination of environment and arg, e.g.: ENV=stuff /path/to/thing --good Add support to custom-env for parsing this, with tests, so we can delete the custom implementation inside desktop-shell. Signed-off-by: Daniel Stone <daniels@collabora.com>
2cdb4736 -
Rather than open-coding our own implementation of parsing a string to construct an envp and an argp, just use custom_env's implementation. Signed-off-by: Daniel Stone <daniels@collabora.com>
965d90cb -
Use the arg handling added in the previous commit so that the environment is completely encapsulated inside the custom env. Signed-off-by: Daniel Stone <daniels@collabora.com>
5dbe0016 -
We already have a helper for this; use it. Signed-off-by: Daniel Stone <daniels@collabora.com>
8b238905 -
Matches the safe Xwayland implementation more closely and makes it easier to reuse it. Signed-off-by: Daniel Stone <daniels@collabora.com>
a3175727 -
This doesn't actually stop us from calling setenv() in between fork() and exec() when starting clients, but gets us closer to Xwayland's safe implementation by reusing one of the helpers it added. Signed-off-by: Daniel Stone <daniels@collabora.com>
c0a76716 -
It was only a small function, and inlining it will allow us to make it more safe without having to duplicate a ton of stuff. Signed-off-by: Daniel Stone <daniels@collabora.com>
8aa45712 -
Use the custom_env framework we added for Xwayland when forking to execute clients. This avoids calling the unsafe getenv in between fork and exec. Signed-off-by: Daniel Stone <daniels@collabora.com>
9ab97ebd -
[common equivalent of 77cf8cb0 in Xwayland from Pekka Paalanen; its commit message follows] Between fork() and exec() in the child process it is only safe to use async-signal-safe functions. weston_log() definitely is not one, it allocates memory and does whatnot. weston_log() is also inappropriate for other reasons: the child process has its own stream buffers and flight-recorder. No-one looks into the child process' flight recorder, so messages would be lost there. The logging machinery might also attempt to write into debug streams, meaning both parent and child could be writing simultaneously. It seems that the best we can do is to pre-bake an error message and only write() it out if exec() fails. There is no mention that even strerror_r() might be safe to call, so we don't. Signed-off-by: Daniel Stone <daniels@collabora.com>
53f895b4
shared/process-util.c
0 → 100644
shared/process-util.h
0 → 100644
tests/custom-env-test.c
0 → 100644