We never printed the capture stderr, which makes things hard to debug.

There are still usages of the user env file which do not make the
service start, for example tca and tails-autotest-remote-shell.

boyska authored Mar 15, 2023 and segfault committed Mar 15, 2023

This reverts commit f7065ff2.
We don't need it anymore because the new code doesn't have the issue at
all

run-with-user-env now waits until user services can be started and the
gnome-shell Wayland session is ready, so we don't need these wait loops
anymore.

This causes run-with-user-env to block until tails-dump-user-env.service
was started to ensure that the user-env file exists. This fixes some
race conditions in cases where run-with-user-env was used at a point
where tails-dump-user-env.service might not have started yet.

This caused failures because PATH was not set.

This helps debugging

and exec-with-user-env -> run-with-user-env

boyska authored Mar 09, 2023 and segfault committed Mar 15, 2023

this is not just vanity: the previous parser could be abused to allow
privilege escalation from tails-persistent-storage to amnesia

It's unexpected given the name of the function and we don't to use the
current env in all the usages of that function, for example when
processes running as root call read_user_env(user="amnesia"), we don't
want the current environment from the root process to be used.

To avoid code duplication.

Also reimplement dump-user-env in Python so that we can maintain the
list of allowed and dumped environment variables in one place.

We don't use it anywhere else anymore and it really does belong to the
tps package.

The script is now a bash script, so $EUID is always set by the shell.

Makes debugging easier

Dumping all environment variables caused failure in the test suite where
we use the environment dumped by amnesia in a root process. That caused
the PATH variable to not include /sbin anymore.

The environment variables we dump here are the same that were dumped in
the old implementation in gnome.sh.

I had a case where "poweroff" did not cause the system to shut down
but "systemctl poweroff" worked.

There are cases where we execute commands as a user when the user env
file is not expected to be there, for example when we create files in
persistent directories as the owner of the directory, which in case of
the persistent greeter settings happens as the Debian-gdm but after
login, so systemd already cleaned up the user env file for Debian-gdm.

The script doesn't need privileges, so we should run it unprivileged.

The environment we're dumping doesn't actually have anything to do with
GNOME or GNOME Shell, it's the default environment of a user unit
started by systemd plus some display related variables set by us in
dump-user-env. The name user-env therefore better reflects its content.

Also use the name exec-with-user-env instead of exec-in-user-env to make
it more clear that we're not replacing the current environment.