Perguntas[systemd](unix)

Eu tenho esse script que funciona:

#! /usr/bin/bash

export SEQVAL=$(date +%s) &&  sed -i "s/^SEQ1=.*$/SEQ1=${SEQVAL}/" /etc/environment
systemctl restart ccs-srvapp-telemetry.service

Não consigo fazer o que foi dito acima funcionar corretamente em um arquivo de unidade.

a última encarnação que tenho está abaixo, mas houve várias tentativas com várias configurações, todas falhando porque a variável não foi definida ou algo não escapou corretamente no comando sed.

[Unit]
Description=restarts fluent bit with a new SEQ1 to force a logrotate
After=network.target


[Service]
Type=oneshot
EnvironmentFile=/etc/environment
ExecStart=/usr/bin/sh -c 'export SEQVAL=$(date +%s) && sed -i "s/^SEQ1=.*$/SEQ1=${SEQVAL}/" /etc/environment'
ExecStartPost=/bin/systemctl restart ccs-srvapp-telemety.service


[Install]
WantedBy=multi-user.target

Quero aprender sobre o backdoor do XZ Utils seguindo a demonstração do exploit xzbot e configurando o ambiente . Sei que a versão 5.6.1 do xz-utils deve ter o backdoor, mas não consigo instalar esse pacote comprometido.

Começando com um ambiente limpo Kali Linux 2024.4, ele tem liblzma 5.6.3 e sshdnão parece depender de libsystemd e liblzma. Aparentemente, nem o OpenSSH de estoque nem o portátil vêm com suporte ao systemd. Estou confuso com todos os guias que esperam sshdjá estar vinculados ao liblzma, enquanto ele simplesmente não é para mim.

└─$ dpkg -l | grep liblzma5
ii  liblzma5:amd64                                 5.6.3-1+b1                               amd64        XZ-format compression library

└─$ ldconfig -p | grep liblzma
        liblzma.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/liblzma.so.5

└─$ sshd -V
OpenSSH_9.9p1 Debian-3, OpenSSL 3.3.2 3 Sep 2024

└─$ ldd $(which sshd)
        linux-vdso.so.1 (0x00007fc3de0b8000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fc3ddfde000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fc3dda00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc3dd80a000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fc3dd768000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc3de0ba000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc3ddfbe000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fc3dd6a7000)

Ao fazer o downgrade para o pacote liblzma 5.6.1 e verificar lddnovamente, nada parece ter mudado.

└─$ wget https://snapshot.debian.org/archive/debian/20240328T025657Z/pool/main/x/xz-utils/liblzma5_5.6.1-1_amd64.deb             
2024-12-24 00:45:29 (4.72 MB/s) - ‘liblzma5_5.6.1-1_amd64.deb’ saved [252188/252188]

└─$ sudo dpkg -i ./liblzma5_5.6.1-1_amd64.deb
dpkg: warning: downgrading liblzma5:amd64 from 5.6.3-1+b1 to 5.6.1-1
(Reading database ... 425071 files and directories currently installed.)
Preparing to unpack ./liblzma5_5.6.1-1_amd64.deb ...
Unpacking liblzma5:amd64 (5.6.1-1) over (5.6.3-1+b1) ...
Setting up liblzma5:amd64 (5.6.1-1) ...
Processing triggers for libc-bin (2.40-3) ...

└─$ dpkg -l | grep liblzma5
ii  liblzma5:amd64                                 5.6.1-1                                  amd64        XZ-format compression library
                                                                                          
└─$ sudo systemctl restart ssh

└─$ ldd $(which sshd)                                                                                               
        linux-vdso.so.1 (0x00007f705e59b000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f705e4c1000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f705de00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f705dc0a000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f705e41f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f705e59d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f705e3ff000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f705db49000)

Então eu tentei construir o OpenSSH 9.7p1, já que isso foi antes do backdoor se tornar público, se isso talvez ajudasse. Isso exigiu uma reinicialização antes de sshd -Vmostrar 9.7p1

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
tar -xvf openssh-9.7p1.tar.gz
cd openssh-9.7p1
sudo apt install libssl-dev
./configure
make
sudo make install

Mas tanto o libsystemd quanto o liblzma ainda não estavam vinculados ao sshd.

Neste ponto, não tenho a mínima ideia de como instalar ou construir o pacote vulnerável xz-utils. Tive problemas semelhantes ao tentar os mesmos passos com o Ubuntu 24.04

Ambiente

Este é um servidor vps Ubuntu 22.04.5. O Wireguard usa tuntap em vez do kernel mod.

Roteiro

/etc/wireguard/gw0.shpode iniciar o wireguard corretamente se executado a partir da linha de comando:

# cleanup
echo "$(date) - cleanup"
/usr/sbin/ip link del gw0 2>&1
/usr/sbin/iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o venet0 -j MASQUERADE 2>&1

# setup
echo "$(date) - setup"
#/usr/sbin/ip tuntap add dev gw0 mode tun
/usr/bin/wireguard gw0 2>&1
/usr/sbin/ip a add 10.0.0.1/24 dev gw0
/usr/bin/wg set gw0 listen-port 12345
/usr/bin/wg set gw0 private-key /etc/wireguard/gw0.key
# wg0
/usr/bin/wg set gw0 peer <wg0 key> allowed-ips 10.0.0.2/32
# wg1
/usr/bin/wg set gw0 peer <wg1 key> allowed-ips 10.0.0.3/32

# start
echo "$(date) - start"
/usr/sbin/ip link set gw0 up 2>&1
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o venet0 -j MASQUERADE 2>&1

# end
echo "$(date) - end"

exit 0

Saída:

# /etc/wireguard/gw0.sh
Thu Dec  5 10:03:32 EST 2024 - cleanup
Cannot find device "gw0"
Thu Dec  5 10:03:32 EST 2024 - setup
┌──────────────────────────────────────────────────────┐
│                                                      │
│   Running wireguard-go is not required because this  │
│   kernel has first class support for WireGuard. For  │
│   information on installing the kernel module,       │
│   please visit:                                      │
│         https://www.wireguard.com/install/           │
│                                                      │
└──────────────────────────────────────────────────────┘
Thu Dec  5 10:03:32 EST 2024 - start
Thu Dec  5 10:03:33 EST 2024 - end

Serviço Systemd

/etc/systemd/system/gw0.service:

[Unit]
Description = Start Wireguard gw0
After = network-online.target
Wants = network-online.target
[Service]
Type = oneshot
ExecStart = /usr/bin/bash -c "/etc/wireguard/gw0.sh >> /tmp/gw0.log"

[Install]
WantedBy=multi-user.target

Iniciar o serviço sempre resultará em erro de tempo limite e nenhum processo wireguard:

# systemctl start gw0.service
Job for gw0.service failed because a timeout was exceeded.
See "systemctl status gw0.service" and "journalctl -xeu gw0.service" for details.

# systemctl status gw0.service
× gw0.service - Start Wireguard gw0
     Loaded: loaded (/etc/systemd/system/gw0.service; disabled; vendor preset: enabled)
     Active: failed (Result: timeout) since Thu 2024-12-05 10:12:07 EST; 34s ago
    Process: 95515 ExecStart=/usr/bin/bash -c /etc/wireguard/gw0.sh >> /tmp/gw0.log (code=exited, status=0/SUCCESS)
   Main PID: 95515 (code=exited, status=0/SUCCESS)

Dec 05 10:10:37 mybox systemd[1]: Starting Start Wireguard gw0...
Dec 05 10:12:07 mybox systemd[1]: gw0.service: State 'stop-sigterm' timed out. Killing.
Dec 05 10:12:07 mybox systemd[1]: gw0.service: Failed with result 'timeout'.
Dec 05 10:12:07 mybox systemd[1]: Failed to start Start Wireguard gw0.

# journalctl -xeu gw0.service
Dec 05 10:10:37 mybox systemd[1]: Starting Start Wireguard gw0...
░░ Subject: A start job for unit gw0.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit gw0.service has begun execution.
░░
░░ The job identifier is 2611.
Dec 05 10:12:07 mybox systemd[1]: gw0.service: State 'stop-sigterm' timed out. Killing.
Dec 05 10:12:07 mybox systemd[1]: gw0.service: Failed with result 'timeout'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit gw0.service has entered the 'failed' state with result 'timeout'.
Dec 05 10:12:07 mybox systemd[1]: Failed to start Start Wireguard gw0.
░░ Subject: A start job for unit gw0.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit gw0.service has finished with a failure.
░░
░░ The job identifier is 2611 and the job result is failed.

No entanto, /tmp/gw0.logmostra o script concluído:

Thu Dec  5 10:10:37 EST 2024 - cleanup
Thu Dec  5 10:10:37 EST 2024 - setup
┌──────────────────────────────────────────────────────┐
│                                                      │
│   Running wireguard-go is not required because this  │
│   kernel has first class support for WireGuard. For  │
│   information on installing the kernel module,       │
│   please visit:                                      │
│         https://www.wireguard.com/install/           │
│                                                      │
└──────────────────────────────────────────────────────┘
Thu Dec  5 10:10:37 EST 2024 - start
Thu Dec  5 10:10:37 EST 2024 - end

Pergunta

Alguém tem ideia de como fazer gw0.servicefuncionar?

O arquivo de unidade systemd não pode ser executado manualmente, então deve haver algo que o acione. Dependências reversas podem exigir isso, mas como elas também são iniciadas? Normalmente, elas não são iniciadas antes startx(ou pelo menos não deveriam ser), então deve haver um ponto de acionamento.

Estou mais interessado em como ele funciona com o startx, e não com um gerenciador de login.

Detalhes sobre como gnome-session.targetfunciona especificamente também seriam ótimos, já que é o exemplo mais prático de uma implementação de framework de sessão que utiliza graphical-session.target. O binário gnome-session tem uma --systemdopção. Talvez seja onde o gatilho do ponto de partida é colocado. Seria triste saber que os binários podem simplesmente ignorar RefuseManualStart=yes. Isso seria muito... gatilho.

A RequiresMountsFor=opção em um arquivo de unidades systemd requer que a montagem para os caminhos especificados esteja no lugar antes que a unidade seja iniciada.

Até onde eu sei, argumentos podem ser um ponto de montagem, bem como qualquer diretório abaixo desse ponto de montagem. Por exemplo, se os arquivos de zona para BIND estiverem em /etc/binde /etcestiverem em seu próprio sistema de arquivos, RequiresMountsFor=/etcou RequiresMountsFor=/etc/bindatingirão o resultado desejado: BIND não iniciará até que /etctenha sido montado e, portanto, /etc/bindesteja disponível.

Agora estou imaginando o que aconteceria se RequiresMountsFor=eu especificasse um caminho inexistente. Por exemplo, if fstabtem entradas para /and /etcmas nada abaixo de /etc, and RequiresMountsFor=/etc/this/path/does/not/existrefere-se a um caminho que não existe em /etc.

Isso faria com que a unidade esperasse para /etcser montada (já que é o último ponto de montagem no caminho)? Se sim, a unidade iniciaria assim que /etcfosse montada ou falharia porque /etc/this/path/does/not/existnão foi encontrada?

Isso pode se tornar relevante onde as unidades aceitam parâmetros, como [email protected], que tem RequiresMountsFor=/etc/postgresql/%I /var/lib/postgresql/%I. Se os arquivos de dados de um cluster forem movidos para longe, o segundo caminho não apontará para lugar nenhum se a unidade for invocada naquele cluster.

A saída de lsnsparece diferente com base no privilégio do usuário que o executa. ubuntuusuário e rootusuário obtêm resultados diferentes:

ubuntu@ubuntu:~$ lsns 
        NS TYPE   NPROCS    PID USER   COMMAND
4026531834 time        6 134628 ubuntu /lib/systemd/systemd --user
4026531835 cgroup      6 134628 ubuntu /lib/systemd/systemd --user
4026531836 pid         6 134628 ubuntu /lib/systemd/systemd --user
4026531837 user        5 134628 ubuntu /lib/systemd/systemd --user
4026531838 uts         6 134628 ubuntu /lib/systemd/systemd --user
4026531839 ipc         6 134628 ubuntu /lib/systemd/systemd --user
4026531840 net         6 134628 ubuntu /lib/systemd/systemd --user
4026531841 mnt         5 134628 ubuntu /lib/systemd/systemd --user
4026532290 user        1 134689 ubuntu /usr/bin/podman
4026532291 mnt         1 134689 ubuntu /usr/bin/podman
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ sudo lsns
        NS TYPE   NPROCS    PID USER             COMMAND
4026531834 time      115      1 root             /sbin/init
4026531835 cgroup    115      1 root             /sbin/init
4026531836 pid       112      1 root             /sbin/init
4026531837 user      113      1 root             /sbin/init
4026531838 uts       112      1 root             /sbin/init
4026531839 ipc       115      1 root             /sbin/init
4026531840 net       115      1 root             /sbin/init
4026531841 mnt       101      1 root             /sbin/init
4026531862 mnt         1     25 root             kdevtmpfs
4026532284 mnt         1    414 root             /lib/systemd/systemd-udevd
4026532285 uts         1    414 root             /lib/systemd/systemd-udevd
4026532286 mnt         1    469 systemd-timesync /lib/systemd/systemd-timesyncd
4026532287 uts         1    469 systemd-timesync /lib/systemd/systemd-timesyncd
4026532288 mnt         1    572 systemd-network  /lib/systemd/systemd-networkd
4026532289 mnt         1    608 systemd-resolve  /lib/systemd/systemd-resolved
4026532290 user        1 134689 ubuntu           /usr/bin/podman
4026532291 mnt         1 134689 ubuntu           /usr/bin/podman
4026532292 mnt         1   5369 root             /usr/libexec/upowerd
4026532293 user        1   5369 root             /usr/libexec/upowerd
4026532295 mnt         2 134974 root             unshare --fork --pid --mount-proc /bin/bash
4026532296 pid         2 134975 root             /bin/bash
4026532297 mnt         2 134981 root             unshare --fork --pid --mount-proc /bin/zsh
4026532298 pid         1 134982 root             /bin/zsh
4026532345 uts         1    655 root             /lib/systemd/systemd-logind
4026532346 mnt         1    631 root             /usr/sbin/irqbalance --foreground
4026532347 mnt         1    655 root             /lib/systemd/systemd-logind
4026532348 mnt         1    678 root             /usr/sbin/ModemManager
ubuntu@ubuntu:~$

Além disso, o nome do processo init do sistema Ubuntu é diferente: systemdvs /sbin/init. Qual é o motivo disso? Obrigado.

Estou tendo alguns problemas com a inicialização de um Ubuntu 24.04.1 novo da Intel Optane (que acabei de receber do eBay): o processo de inicialização é rápido, mas de vez em quando algumas unidades systemd não são executadas durante a inicialização, o sistema inicia sem o NetworkManager ou algo como snapd-apparmor. O log journalctl relata que há ciclos de ordenação. Tentando encontrá-los, percebi que ele systemd-analyze verify multi-user.targetrelata coisas diferentes quase toda vez que o executo:

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
7
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
13
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
0
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
0
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
18

Desconfiado do disco do eBay, tentei o mesmo no Ubuntu 22.04 instalado anteriormente em um Corsair NVMe, com os mesmos resultados:

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
16
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
22
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
44
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
24
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
4
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
14

O processo de inicialização no Corsair NVMe tem problemas semelhantes com a não inicialização de algumas unidades systemd. Mas é menos frequente.

Por que isso está acontecendo? Eu perdi algo sobre systemd-analyze verify? Como é systemd-analyze verifypossível relatar um número diferente de ciclos toda vez que você o executa?

As versões. No Intel Optane:

$ systemd --version
systemd 255 (255.4-1ubuntu8.4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"

E a instalação anterior no Corsair NVMe ( lspcina verdade, é relatado como Phison Electronics Corporation E12):

$ systemd --version
systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS"

Eu entro no wish SSH como um usuário "Ubuntu" em um servidor. No entanto, quero gerenciar a execução de alguns serviços systemd como outro usuário "ABC".

Se eu tentar sudo -u abc bashcomo usuário ABC, todo systemd --usercomando dará o erro:

Failed to connect to bus: No medium found

Encontrei este tópico que sugeriu adicionar o seguinte a ~/.bashrc:

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

Isso altera o erro para:

Failed to connect to bus: No such file or directory

Outras fontes sugeriram que servidores headless normalmente não têm dbus instalado, então isso faz sentido (parece ser um componente do x11). Embora eu não saiba por que funciona sem problemas se eu o executo como ubuntu.

Encontrei esta solução alternativa sugerida

sudo systemctl -M abc@ --user restart foobar.service

Isso funciona para start, , básico stop, statusmas:

• systemctl --user catnão funciona
• Nenhuma variação journalctlparece funcionar:

Failed to open root directory of machine 'abc@': The name org.freedesktop.machine 1 was not provided by any .service files
Failed to open journal: No route to host

• É muito longo para digitar e inconveniente.

Eu realmente só quero um shell para esse outro usuário, assim como quando eu entro ubuntu, e posso gerenciar todos os meus serviços de usuário sem problemas.

Menciono o Podman porque o Podman também fica realmente infeliz quando o executo como um usuário diferente. Ele funciona bem se eu o uso como, ubuntumas dá erros se eu o executo com sudo -u. Como o systemd, tenho algumas soluções alternativas parciais, mas nenhuma parece funcionar bem.

Tenho duas interfaces de rede, eno1 e eth0. Gostaria que ambas usassem DHCP para obter um endereço IP. Gostaria que eno1 fosse usado como rota padrão para tudo. A única vez que quero usar eth0 é ao especificar interface em um comando curl.

Criei dois arquivos de configuração:

root:/etc/systemd/network$ ls -la
total 16
drwxr-xr-x 2 root root 4096 Oct 20 10:50 .
drwxr-xr-x 6 root root 4096 Oct 20 10:51 ..
-rw-r--r-- 1 root root   59 Oct 20 09:54 10-eno1.network
-rw-r--r-- 1 root root   59 Oct 20 10:41 20-eth0.network

root:/etc/systemd/network$ cat 10-eno1.network
[Match]
Name=eno1

[Network]
DHCP=yes

[Route]
Metric=100

root:/etc/systemd/network$ cat 20-eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes

[Route]
Metric=4000

Tentei reiniciar e mexer nas métricas, mas elas não surtiram efeito.

root:/etc/systemd/network$ systemctl status systemd-networkd
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-10-20 10:51:59 UTC; 12min ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   Main PID: 24821 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 76956)
   FD Store: 0 (limit: 512)
     Memory: 1.7M (peak: 2.1M)
        CPU: 32ms
     CGroup: /system.slice/systemd-networkd.service
             └─24821 /usr/lib/systemd/systemd-networkd

Oct 20 10:51:59 systemd-networkd[24821]: eth0: Link UP
Oct 20 10:51:59 systemd-networkd[24821]: eth0: Gained carrier
Oct 20 10:51:59 systemd-networkd[24821]: eno1: Gained IPv6LL
Oct 20 10:51:59 systemd-networkd[24821]: eth0: Gained IPv6LL
Oct 20 10:51:59 systemd-networkd[24821]: Enumeration completed
Oct 20 10:51:59 systemd[1]: Started systemd-networkd.service - Network Configuration.
Oct 20 10:51:59 systemd-networkd[24821]: eno1: Configuring with /etc/systemd/network/10-eno1.network.
Oct 20 10:51:59 systemd-networkd[24821]: eth0: Configuring with /etc/systemd/network/20-eth0.network.
Oct 20 10:51:59 systemd-networkd[24821]: eno1: DHCPv4 address 192.168.0.2/24, gateway 192.168.0.1 acquired from 192.168.0.1
Oct 20 10:51:59 systemd-networkd[24821]: eth0: DHCPv4 address 192.168.0.99/24, gateway 192.168.0.1 acquired from 192.168.0.1

root:/etc/systemd/network$ ip route show
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.2 metric 1024
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.99 metric 1024
128.138.140.44 via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.2 metric 1024
128.138.140.44 via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.99 metric 1024
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.2 metric 1024
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.99 metric 1024
192.168.0.1 dev eno1 proto dhcp scope link src 192.168.0.2 metric 1024
192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.99 metric 1024

Tentando executar um serviço systemd com systemctl --user start foo.servicewhich contém ExecStart=touch /bar/bazwhere /barhas permissions drwxrwxr-x 1 root storage. O usuário que está executando o comando pertence ao grupo storagee pode executar o touchcomando do shell sem problemas, criando o arquivo. O serviço, no entanto, falha com um erro de permissão.

Pensei que as permissões do serviço corresponderiam ao usuário que o executa - e, de fato, fazer com que o serviço use a ${USER}variável de ambiente em seu comando produz meu usuário, e o serviço aparece em minhas listas psou .pstree ${USER}

foo.servicenão contém ProtectSystemou qualquer entrada diferente de: Description, EnvironmentFile, Environment, ExecStart, KillSignal, Restart, RestartSec. As entradas de ambiente são para carregar configuração não relacionada a permissão.

O serviço não usa realmente o usuário chamador para permissões? E se não, qual seria a melhor abordagem para resolver o problema? /barestá em uma unidade montada, então posso apenas dmask 0000no meu fstab, mas prefiro evitar essa abordagem.