Sì, sarebbe decisamente pessimo. Sto solo cercando argomenti più pesanti sul motivo per cui il design di systemd è il modo in cui è (sicurezza).
Questo è un follow up su domanda interessante su U & L . La domanda discute sul fatto che al logout utente systemd è in attesa (il predefinito, configurabile) 90 secondi per la disponibilità di un disco, l'utente sa che il disco non è presente e desidera saltare tale attesa. Io sostengo che l'unica opzione è configurare systemd per usare un ritardo più breve. Questo perché consentire a un utente non privilegiato di dare istruzioni (diciamo attraverso un segnale di interruzione) a systemd sarebbe un problema.
Ad esempio: un utente senza privilegi che può inviare segnali a systemd potrebbe attendere un amministratore per riavviare SELinux e provocare un errore durante l'avvio. Questo è l'esempio che ho preso dalla mia testa.
Ora, supponiamo che qualcuno scriva effettivamente un wrapper per il logout utente che verrà eseguito in setuid , questo verrà fatto per un "facile utilizzo" di systemd (ad esempio, invia un interrupt che disabiliterà il timeout prima di un SIGKILL viene inviato a un processo che non è terminato con SIGTERM). Questo non è particolarmente difficile da scrivere, puoi semplicemente creare uno script e aggiungerlo alla configurazione del display manager ( lighdm ha session-cleanup-script= , gdm ha PostSession script, o anche un semplice .bash_logout per headless macchine). Il wrapper consentirà una comunicazione con l'interfaccia SIGNAL di systemd , che è in man systemd nella sezione SIGNALS .
Per focalizzare la domanda, diamo un'occhiata all'escalation dei privilegi. Ad esempio, se un utente malintenzionato è riuscito a ottenere l'accesso a un account utente senza privilegi e ora può dare comandi a systemd tramite tale wrapper, come potrebbe inoltrare i privilegi a un account root ?