Perché sudo -i non imposta XDG_RUNTIME_DIR per l'utente di destinazione?

XDG_RUNTIME_DIRè necessario per systemctl --userfunzionare.

Ho installato Ubuntu Server 16.04 per eseguire sessioni utente di systemd. Ora, quando provo ad amministrarli, scopro che quando si cambia un utente via sudo -u $user -io anche su - $user, l'ambiente non si è XDG_RUNTIME_DIRimpostato, impedendo il systemctl --userfunzionamento. Tuttavia, quando mi rivolgo sshdirettamente a quell'utente, è impostato correttamente.

Se capisco correttamente la documentazione, questo dovrebbe essere impostato libpam-systemddurante la creazione della sessione utente. La sezione utente viene avviata correttamente, poiché esiste la directory in cui XDG_RUNTIME_DIRdovrebbe puntare ( /run/users/$uid). Sono titubante nel codificarlo, diciamo, .bash_profileperché sembra confuso (anche se funziona), quando il pam dovrebbe occuparsene.

Naturalmente, posso aggiungere XDG_RUNTIME_DIRad env_keepin sudoers, ma ciò preserverebbe semplicemente l'ambiente dell'utente sudoing, che non è quello che voglio. Voglio l' ambiente dell'utente di destinazione .

Quello che mi chiedo davvero, però, è come mai la sessione è impostata correttamente ssh, ma non con suo sudo -i?

Ho replicato questo problema sul mio sistema Fedora 25.

Ho trovato una condizione molto sospetta nel codice sorgente. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Sembra che sia stato scritto sudopensando al normale ma non sudo -u non-root-user.

machinectl shell --uid=non-root-user ha funzionato come da lei richiesto.

systemd-run non sembrava funzionare come desiderato, nonostante il riferimento ad esso nella documentazione di machinectl.

Alcuni comandi di machinectl non funzionano se hai abilitato SELinux al momento, e questi comandi specifici non hanno funzionato per me fino a quando non l'ho fatto setenforce 0. Comunque sono nel mezzo del tentativo di soluzioni alternative per far funzionare machinectl come voglio che scriva SELinux, quindi è possibile che il mio armeggiare sia ciò che provoca ad esempio il machinectl shelltimeout.

EDIT: penso che questo codice sia stato introdotto dopo questa discussione . E apparentemente su -/ sudo -ipotrebbe essere fatto funzionare, ma nessuno l'ha implementato (ancora).

Quello che mi chiedo davvero, però, è come mai la sessione è impostata correttamente con ssh, ma non con su o sudo -i?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

Siamo spiacenti, ma "su" è uno strumento per modificare temporaneamente le identità degli utenti e pochissime altre credenziali di processo. Non è uno strumento per aprire una sessione di accesso completamente nuova. Una nuova sessione di accesso ha una configurazione molto ben definita e incontaminata, che non eredita nulla da qualsiasi altra sessione, ma questo non è davvero il caso delle modifiche "su" uid: la maggior parte dell'ambiente di esecuzione è ereditato, in numerose e non ovvie modi, ad esempio contesti MAC, contesti di audit, contesti di cgroup, contesti di spazi dei nomi, pianificazione, granularità del timer, ...

se vuoi una nuova sessione completa, usa qualcosa come "login machinectl" o "shell machinectl", che in realtà renderà il tuo ambiente di distacco completamente pulito, indipendente, senza proprietà di processo nascoste che fuoriescono da dove lo chiami.

le sessioni di logind sono per lo più legate al concetto della sessione di audit e le sessioni di audit rimangono inalterate da "su", in realtà sono definite "sigillate", ovvero in modo tale che se un processo entra in una sessione una volta, rimarrà sempre con esso, e così anche i suoi figli, vale a dire che l'unico modo per ottenere una nuova sessione è rinunciare a qualcosa dal PID 1 (o qualcosa di simile) che non ha mai fatto parte di una sessione.

O per dirlo diversamente: le cose che invochi attraverso "su" appariranno bene in "loginctl", tuttavia, rimane parte della sessione originale, hai effettuato l'accesso originariamente. Puoi verificarlo invocando "stato loginctl" sull'ID della sessione originale (che puoi vedere attraverso l'eco $ XDG_SESSION_ID)