In that case let’s go for it? If it can give sandboxed access to audio then that’s a big win IMO. I don’t think any of our users care about the bells and whistles pulseaudio has.
Feel free to open it because it is a large improvement.
Not necessarily. We mount an empty tmpfs over /run so those Wayland files are totally inaccessible currently. Something like this might help:
## Mount the wayland files from the user that executes
## sandbox-app-launcher (SUDO_UID) to the app (app_uid)
## sandbox.
app_uid="$(id -u "${app_user}")"
for wl_file in /run/user/${SUDO_UID}/wayland*
do
if [ -f "${wl_file}" ]; then
bwrap_args+="--ro-bind-try ${wl_file} /run/user/${app_uid}/$(echo "${wl_file}" | awk -F "/" '{print $NF}') "
bwrap_args+="--setenv XDG_RUNTIME_DIR /run/user/${app_uid} "
fi
done
DAC permissions would likely still be an issue however. A chmod / chown would fix that though.
That would be a system-wide change, possibly worsening security. It’d be difficult to do it seamlessly and without opening up security issues. We could probably change DAC permissions from within the sandbox but that would require CAP_DAC_OVERRIDE and implementing it securely would be complicated.
I still don’t like the idea of creating any system-wide changes to this. It may be better to enter the sandbox as root with CAP_DAC_OVERRIDE, modify the file permissions within the mount namespace so it doesn’t affect outside of the sandbox and then switch users / drop privileges.
Let’s assume that I created a proxy UNIX domain socket as wayland user with a proxy program. I would need to find a way to transfer the socket to tmpfs on a new mount namespace and change the owner of the socket.
To do that, the proxy program needs to have access to wayland’s mount namespace and a new wayland client’s mount namespace.
visudo is a good idea but insufficient. We can write to a temporary file. Then use visudo as a sanity check. But even if we verified using visudo that the file is valid, writing into /etc/sudoers.d needs to be atomic. I am worried about file system inconsistency. For example, power loss during writing the file. Either the file creation is complete and successful or partial and not really part of the file system.
I.e. can
echo "0123456789" > testfile
result in only ending up
01245
on the hard drive if power is lost in the middle of the operation?
#!/bin/bash
set -x
set -e
set -o pipefail
app_user="test"
sudoers_file_content="## test"
mkdir -p /etc/sandbox-app-launcher
## Non-ideal location for temporary file but required for following atomic rename.
## Should not cross potential file system barriers such as /tmp on a different partition than /etc.
echo "$sudoers_file_content" | tee "/etc/sandbox-app-launcher/sandbox-app-launcher_${app_user}" >/dev/null
## Using '>/dev/null' to hide success messages on stdout.
## Would still show error messages if any on stderr.
SUDO_EDITOR='/bin/false' VISUAL='/bin/false' EDITOR='/bin/false' visudo --strict --check --file "/etc/sandbox-app-launcher/sandbox-app-launcher_${app_user}" >/dev/null
## Atomic rename.
mv "/etc/sandbox-app-launcher/sandbox-app-launcher_${app_user}" "/etc/sudoers.d/sandbox-app-launcher_${app_user}"