Sudo come utente diverso e schermata in esecuzione

167

Ho scoperto oggi che lo schermo in esecuzione come utente diverso in cui sudo non funzionerà!

vale a dire

ssh bob@server         # ssh into server as bob
sudo su "monitor" -
screen                 # fails: Cannot open your terminal '/dev/pts/0'

Ho uno script che funziona come l'utente "monitor". Lo eseguiamo in una sessione dello schermo per vedere l'output sullo schermo. Il problema è che abbiamo un certo numero di utenti che accedono con il proprio account (es. Bob, james, susie, ecc ...) e poi sudo nell'utente "monitor". Concedere loro l'accesso all'utente "monitor" è fuori discussione.

sudo gnu-screen

— luckytaxi
fonte

13

È questo l'errore che stai riscontrando? "Impossibile aprire il tuo terminale '/ dev / pts / 0' - controlla."

— Jim,

sì questo è quello. Capisco perché sta succedendo ma esiste una soluzione alternativa?

— luckytaxi,

4

Un commento sui tuoi comandi: continuo a vedere le persone correre sudo su "user" -. Perché non usare sudo -u user -s?

— Andrew Aylett,

2

@Jim: +1 per fornire il messaggio di errore mancante.

— Dennis Williamson,

1

@Andrew La maggior parte dei ragazzi che conosco lo fanno sudo su- penso che sia proprio quello a cui le persone si abituano (nel mio caso è perché non hai bisogno di conoscere alcun flag sudo sudo su- Non penso di aver mai letto la manpage sudo :)

— voretaq7,

246

Prova a correre script /dev/nullcome l'utente suprima di avviare lo schermo: è un piccolo ghetto, ma dovrebbe rendere lo schermo felice.

— voretaq7
fonte

5

Ri: implicazioni per la sicurezza, nessuna delle quali sono a conoscenza (ma ciò non significa che non ce ne siano :) :) - IIRC si basa su un effetto collaterale di "script" che apre un nuovo dispositivo terminale (come viene chiamato dall'utente) e poiché stai inviando l'output dello script a / dev / null non c'è nulla da catturare. È anche sicuramente più sicuro dell'aggiunta di utenti al gruppo tty (IMHO)

— voretaq7

2

@nalply Francamente non dovresti trovare più shell confuse se sei un amministratore di sistema Unix - detto ciò, scriptpuò essere usato per il lancio screen. Quindi devi solo uscire due volte (una volta per screen, una volta per su). (Questo è qualcosa che la scriptpagina man può chiarire per te, se ti prendi il tempo di leggerlo ...)

— voretaq7

10

O semplicemente corri sudo -u bob script -q -c 'screen -dr myscreen' /dev/null. Quindi hai solo un terminale da cui uscire / staccare.

— Andy Shulman,

4

Grazie, questo mi ha salvato. Ma perché questo lo risolve? Da quello che ho capito, stampa tutto da stdout a ... da nessuna parte. E questo in qualche modo risolve lo schermo.

— sudo,

3

@sudo Per fare ciò scriptapre il proprio dispositivo tty, di proprietà dell'utente che lo ha eseguito (guarda dentro /deve vedrai apparire dopo l'esecuzione script). screenquindi prende quel dispositivo tty (che è di proprietà dell'utente in esecuzione, screenquindi non ha problemi ad accedervi). È un lavoro di hacking totale, ma funziona. Guardando alcune delle mie macchine sembra che nuove versioni dello schermo sembrino installare setuid-root, che funziona anche, ma significa che hai un altro binario setuid-root fluttuante, il che rende alcune persone giustamente a disagio.

— voretaq7,

33

Sto usando una funzione wrapper screenper l'utente / i a cui mi rivolgo sudo su. Questa è la funzione wrapper che ho aggiunto agli utenti ~/.bashrc:

schermata delle funzioni () {
  / usr / bin / script -q -c "/ usr / bin / screen $ {*}" / dev / null
}

Questo mi permette di usare tutte le opzioni e i parametri per screencui potrei voler usare. Sto pensando di mettere questa funzione in tutto il sistema.

— steviethecat
fonte

1

Funziona perfettamente. Per coloro che desiderano questo a livello di sistema, consiglio di aggiungerlo a /etc/bash.bashrc - funziona su tutti gli utenti.

— Someguy123,

2

Questo non citerà argomenti per schermare correttamente, altrimenti una buona soluzione.

— agosto

7

Supponendo che siano SSH nell'host, è possibile aggiungere le chiavi ssh pubbliche per ciascun utente che deve accedere all'account di monitoraggio nel file ~ monitor / .ssh / authorized_keys. Quindi sul computer remoto di ciascun utente possono eseguire

ssh -t monitor@remote.machine screen -RD

— alex
fonte

Questo è un altro buon approccio - Dovresti specificare i comandi forzati nel file delle chiavi autorizzate (per la nota precedente di "dare loro l'accesso all'utente 'monitor" è fuori discussione "i comandi forzati potrebbero limitarli a solo allegato alla sessione schermo)

— voretaq7,

2

Non ero sicuro di come risolverlo nella mia risposta, perché ha detto che "dare loro l'accesso ... è fuori discussione", ma ha anche detto "... sudo nell'utente" monitor ". Ma sono d'accordo, forzare la restrizione dei comandi negli amministratori autorizzati dovrebbe occuparsene.

— Alex,

7

Supponendo che stiamo parlando di questo errore:

$ sudo su - bob
$ screen
Cannot open your terminal '/dev/pts/5' - please check.

Ecco un one-liner (potrebbe essere usato come "alias gobob", ad esempio):

sudo su - bob -c "script -c bash /dev/null"'

Spiegazione:

Questo avvierà una shell (come la shell di login) come bob utente. L'utente bob si avvia script, a cui viene detto di invocare un bash (potrebbe essere trattino o ksh ...) e una copia della sessione viene eliminata.

— basic6
fonte

0

Probabilmente dovrei cambiare le autorizzazioni sul dispositivo in questione o aggiungere il monitor a un gruppo che ha il permesso di leggere quel dispositivo, sarebbe la mia prima inclinazione. Ma dovresti soppesare le implicazioni di sicurezza di farlo.

— Bart Silverstrim
fonte

0

Dici di fare:

sudo su "monitor" -

Mi chiedo del trattino finale. Di solito faccio:

sudo su - username

Il trattino (per la pagina man di su) dice a "di rendere la shell una shell di login". Ciò significa che genererà tutti i soliti script di avvio della shell e imposterà correttamente cose come PATH e HOME.

— Doug Harris
fonte

3

No. sudo su - usernamee sudo su username -fare la stessa cosa.

— Tim Ludwinski,

-4

Ho appena colpito questo problema. Risolto con chmod +rw $(tty)prima di eseguire sudo. Il problema con questa soluzione è che chiunque può connettersi e curiosare sul terminale dopo.

— Amos Shapira
fonte

2

Sembra un'ottima soluzione.

— Evan Carroll,

10

@EvanCarroll È un'ottima soluzione, tranne la parte in cui dà al mondo intero l' accesso in lettura e scrittura al suo terminale. Solo un piccolo problema di sicurezza: nessun programma se ne preoccuperebbe, tranne ovviamente tutto ciò che controlla la sicurezza del terminale prima di accettare le password ( gpgad esempio). E sicuramente non sarà mai su un sistema con utenti malintenzionati che guarderebbero ttye

— annuseranno le

Attenzione : non provarlo mai a casa! Questo è pericoloso!!!

— Ruizpauker,