Posso avviare un programma grafico sul desktop di un altro utente come root?

Di seguito sono riportate altre domande che penso di dover conoscere:

• Da una sessione non X? (significa che root non è registrato in X)

• Se su X sono state eseguite più persone, è possibile rilevare automaticamente chi si trovava su quale schermo e quindi rilevare a livello di programmazione su quale schermo è necessario avviare l'app?

• Posso avviare l'app come utente? (ok sono sicuro al 99,999% che si tratta di un sì)

• Posso rilevare se gli utenti del gruppo X hanno effettuato l'accesso a X?

Per avviare un programma grafico sul desktop di un utente, devi trovare due cose: quale display è il desktop dell'utente (l'indirizzo) e quale cookie di autorizzazione usare (la password).

Il comando seguente dovrebbe elencare i display locali a cui l'utente ha effettuato l'accesso (uno per riga) sulla maggior parte degli unices:

who | awk -v user="$target_user" '$1 == user && $2 ~ "^:" {print $2}'

Trovare il cookie di autorizzazione è un po 'più difficile. Devi cercare il file cookie dell'utente, che è ~/.Xauthorityper impostazione predefinita (tutto ciò che serve è la posizione del file cookie, non è necessario estrarre il cookie da esso). Funziona su molti sistemi, ma non tutti; dipende dal display manager e da come è impostato, e in particolare Gdm (il default su Ubuntu) non ha usato la posizione predefinita per l'ultima volta. Non riesco a pensare a un modo portatile per scoprire il file X cookie attuale. Il modo più accurato per scoprirlo è scoprire il pid del processo X e cercare l'argomento per l' -authopzione. Un altro modo è trovare un processo in esecuzione su quel server X e catturare la sua XAUTHORITYvariabile di ambiente. Se hai problemi a trovare il file cookie, vediAprire una finestra su un display X remoto (perché "Impossibile aprire il display")?

Una volta che hai entrambe le informazioni, inserisci la visualizzazione scelta nella DISPLAYvariabile d'ambiente, il file del cookie dell'autorità X scelto nella XAUTHORITYvariabile d'ambiente e sei pronto. Non importa quale utente esegue il programma; combinalo con suse ti piace.

Non posso provarlo completamente poiché tutte le mie macchine hanno il root disabilitato.

Per trovare su quale display è attivo un utente, puoi usare il whocomando. L'ultima colonna di output è di solito il DISPLAY a cui l'utente ha effettuato l'accesso. Qualcosa del genere potrebbe essere usato per afferrare solo il display (c'è probabilmente un modo molto più efficiente per farlo, sentiti libero di offrire modifiche):

who | grep -m1 ^username.*\( | awk '{print $5}' | sed 's/[(|)]//g'

Quindi per avviare un comando X grafico su quel display:

DISPLAY=:0 firefox &

dove: 0 verrebbe sostituito con qualunque display tu abbia trovato nel primo comando e firefox verrebbe sostituito con qualunque comando tu voglia eseguire. Puoi metterlo in uno script di shell e usare solo una variabile.

La parte successiva è la parte che non ho testato, ma non vedo perché non dovrebbe essere possibile farlo:

su username -c "DISPLAY=:0 firefox"

per lanciare il comando X come quell'utente.

Potresti vedere come lo fa acpid. Ad esempio quando emette comandi xscreensaver o cancella lo schermo per ogni utente che esegue X o X-session.

Ad esempio, in Ubuntu questo file contiene elementi correlati:

/etc/acpi/lid.sh

Contiene questo ciclo:

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        grep -q off-line /proc/acpi/ac_adapter/*/state
        if [ $? = 1 ]
            then
            if pidof xscreensaver > /dev/null; then 
                su $user -c "xscreensaver-command -unthrottle"
            fi
        fi
        if [ x$RADEON_LIGHT = xtrue ]; then
            [ -x /usr/sbin/radeontool ] && radeontool light on
        fi
        if [ `pidof xscreensaver` ]; then
            su $user -c "xscreensaver-command -deactivate"
        fi
        su $user -c "xset dpms force on"
    fi
done

Un'estensione alla risposta di Gilles è come trovare il file cookie. Un modo per farlo potrebbe essere dopo aver impostato la DISPLAYvariabile d'ambiente (come descritto da Gilles), usare straceper trovare l' xhostaccesso ai file . Mi viene in mente qualcosa del genere in BASH:

# Set the DISPLAY variable first
DISPLAY = :0.0
# Use strace on xhost
strace xhost 2>&1 | grep access

L'output del codice sopra sarà simile a:

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
access("/home/someuser/.Xauthority", R_OK) = 0

Come puoi vedere chiaramente, il file cookie apparirà direttamente qui.

Nella mia ricerca per trovare un modo elegante per visualizzare attività GUI o X da un ambiente limitato come le regole udev o dal superutente, ho recentemente creato uno strumento per adattarlo ( per maggiori dettagli ).

xpub è uno script di shell per ottenere le variabili dell'ambiente di visualizzazione X relative al TTY corrente o a un dato.

Questo è un esempio con una regola udev:

IMPORT{program}="/usr/bin/xpub", \
RUN+="/bin/su $env{XUSER} -c '/usr/bin/notify-send Hello'"

$env{ENV}: se l'utente-tty corrente avvia X, altrimenti rimuoverlo.

Il principio è lo stesso per una riga di comando che utilizza export:

export $(xpub) ; su ${XUSER} -c 'notify-send Hello'