Acho que a resposta seria usar login em vez de su para garantir que o módulo pam_systemd seja executado e defina as variáveis, e também como Giacomo apontou, para garantir que apenas um usuário (mais de um como no cenário de subprocesso su gerado) pode alterar arquivos dentro desse ambiente.
O perigo de su pode ser representado visualmente em um sistema usando systemd da seguinte forma:
usando su
root -systemd
root -login # calls pam_systemd and sets XDG_RUNTIME_DIR among others
user1 -bash
user1 -su
user2 -bash # user1 has access to spawned subprocesses?
usando login
root -systemd
root -login # calls pam_systemd and sets XDG_RUNTIME_DIR among others
user2 -bash
Além disso, loginctl não registra o usuário encapsulado pelo sub-processo su/bash , porque o usuário nunca é registrado com systemd-logind.service por pam_systemd.mod .