dryang / rpms / systemd

Forked from rpms/systemd a year ago
Clone
803fb7
From ddad59f50e67a5e36cd9c40e774d28240a6a7c0c Mon Sep 17 00:00:00 2001
803fb7
From: Filipe Brandenburger <filbranden@google.com>
803fb7
Date: Wed, 11 Nov 2015 09:24:34 -0800
803fb7
Subject: [PATCH] test-execute: Clarify interaction of PassEnvironment= and
803fb7
 MANAGER_USER
803fb7
803fb7
@evverx brought up that test-execute runs under MANAGER_USER which
803fb7
forwards all its environment variables to the services. It turns out it
803fb7
only forwards those that were in the environment at the time of manager
803fb7
creation, so this test was still working.
803fb7
803fb7
It was still possible to attack it by running something like:
803fb7
  $ sudo VAR1=a VAR2=b VAR3=c ./test-execute
803fb7
803fb7
Prevent that attack by unsetting the three variables explicitly before
803fb7
creating the manager for the test case.
803fb7
803fb7
Also add comments explaining the interactions with MANAGER_USER and,
803fb7
while it has some caveats, this tests are still valid in that context.
803fb7
803fb7
Tested by checking that the test running with the variables set from the
803fb7
external environment will still pass.
803fb7
803fb7
(cherry picked from commit e1abca2ee42e5938ee1f2542c3eba9e70edb0be2)
803fb7
803fb7
Related: #1426214
803fb7
---
803fb7
 src/test/test-execute.c | 21 +++++++++++++++++++++
803fb7
 1 file changed, 21 insertions(+)
803fb7
803fb7
diff --git a/src/test/test-execute.c b/src/test/test-execute.c
803fb7
index 8def1946d..6e5567c3e 100644
803fb7
--- a/src/test/test-execute.c
803fb7
+++ b/src/test/test-execute.c
803fb7
@@ -143,6 +143,17 @@ static void test_exec_environment(Manager *m) {
803fb7
 }
803fb7
 
803fb7
 static void test_exec_passenvironment(Manager *m) {
803fb7
+        /* test-execute runs under MANAGER_USER which, by default, forwards all
803fb7
+         * variables present in the environment, but only those that are
803fb7
+         * present _at the time it is created_!
803fb7
+         *
803fb7
+         * So these PassEnvironment checks are still expected to work, since we
803fb7
+         * are ensuring the variables are not present at manager creation (they
803fb7
+         * are unset explicitly in main) and are only set here.
803fb7
+         *
803fb7
+         * This is still a good approximation of how a test for MANAGER_SYSTEM
803fb7
+         * would work.
803fb7
+         */
803fb7
         assert_se(setenv("VAR1", "word1 word2", 1) == 0);
803fb7
         assert_se(setenv("VAR2", "word3", 1) == 0);
803fb7
         assert_se(setenv("VAR3", "$word 5 6", 1) == 0);
803fb7
@@ -199,6 +210,16 @@ int main(int argc, char *argv[]) {
803fb7
         assert_se(setenv("XDG_RUNTIME_DIR", "/tmp/", 1) == 0);
803fb7
         assert_se(set_unit_path(TEST_DIR ":") >= 0);
803fb7
 
803fb7
+        /* Unset VAR1, VAR2 and VAR3 which are used in the PassEnvironment test
803fb7
+         * cases, otherwise (and if they are present in the environment),
803fb7
+         * `manager_default_environment` will copy them into the default
803fb7
+         * environment which is passed to each created job, which will make the
803fb7
+         * tests that expect those not to be present to fail.
803fb7
+         */
803fb7
+        assert_se(unsetenv("VAR1") == 0);
803fb7
+        assert_se(unsetenv("VAR2") == 0);
803fb7
+        assert_se(unsetenv("VAR3") == 0);
803fb7
+
803fb7
         r = manager_new(SYSTEMD_USER, true, &m);
803fb7
         if (IN_SET(r, -EPERM, -EACCES, -EADDRINUSE, -EHOSTDOWN, -ENOENT)) {
803fb7
                 printf("Skipping test: manager_new: %s", strerror(-r));