Esegui applicazioni GUI da terminale con privilegio di root

4

Quindi è stato ben documentato che le applicazioni GUI (come gedit o textedit) dovrebbero NOT essere eseguito con sudo. Ubuntu e altri trovano gksu e gksudo (e simili) così domande: cosa otteniamo WE (utenti Mac)? Dato che il kernel di Darwin è costruito su un codice * BSD, presumo che si applichino gli stessi problemi, ma come possiamo aggirare questo?

    
posta agentroadkill 16.06.2014 - 06:16
fonte

4 risposte

3

Per modificare /etc/hosts con il testo sublime:
sudo /Applications/Sublime\ Text.app/Contents/MacOS/Sublime\ Text /etc/hosts

Se devi farlo regolarmente, puoi aggiungere questo snippet al tuo ~ / .bash_profile

#   sudoapp: Runs .app with root privileges
#   Usage: sudoapp /Applications/Name.app /etc/hosts
#   --------------------------------------------------------------------
    sudoapp () {
        sudo "$1/Contents/MacOS/$(defaults read "$1/Contents/Info.plist" CFBundleExecutable)" $2
    }

Le app in esecuzione con privilegi di root utilizzeranno /private/var/root come cartella principale, quindi tutti i file di configurazione e temporanei di proprietà di root che verranno creati nel processo rimarranno dove dovrebbero essere - nella directory home root .
È come accedere come root ed eseguire l'app, ma senza il fastidio di cambiare utente.

Questo metodo funziona su 10.6 - 10.11

Aggiornamento: il TextEdit di Apple si rifiuta di avviarsi se eseguito come root in 10.11 e successivi, quindi ho cambiato il mio esempio per usare Sublime Text invece

    
risposta data 16.06.2014 - 10:01
fonte
3

Sebbene sia possibile avviare un'applicazione grafica come utente root, non è consigliabile. Può funzionare, la maggior parte delle volte, ma evita di fare affidamento su questo comportamento.

Evita root

L'esecuzione di un'applicazione come root non è consigliata perché aumenta notevolmente il rischio di causare problemi con il Mac. L'uso di root dovrebbe essere limitato al più piccolo pezzo di codice possibile con controlli rigorosi sul posto.

Le applicazioni si stanno spostando sempre più verso un design frammentato per evitare di esporre troppa potenza al codice che non lo richiede.

  • Un errore nel codice in esecuzione con i permessi di root è un rischio per la sicurezza.
  • Un errore nel codice senza i permessi di root è molto meno in grado di causare problemi seri.

Ci sono casi limite, ma questi sono sempre più rari. L'introduzione di sandboxing e XPC fanno parte degli sforzi di Apple per ridurre la necessità di fornire un'autorità eccessiva ai processi in esecuzione su OS X.

Strumenti della riga di comando

Se hai bisogno di lavorare con i file come utente root, usa strumenti a linea di comando come vim , emacs o nano . Questi strumenti non si basano sul WindowServer e possono essere lanciati felicemente come root all'interno di un'altra sessione utente:

sudo nano <path to edit>

Strumenti grafici

Se preferisci gli editor grafici, utilizza un editor che funzioni con il design di Mac OS X. BBEdit è un editor eccellente che gestirà correttamente la modifica dei file di proprietà root .

Quando modifichi un file di proprietà principale con BBEdit, viene utilizzato un secondo processo per colmare il divario di permessi tra te e il proprietario del file. Questo processo passa attraverso i percorsi approvati da Apple e garantisce quindi un'esperienza prevedibile, si spera tra le diverse versioni principali di Mac OS X.

Perché? Limiti di WindowServer e ambito di progettazione

Ci sono sottili problemi tecnici con l'avvio di un'applicazione grafica all'interno di un'altra sessione utente.

I problemi tecnici sottostanti derivano da un utente che desidera avviare un processo grafico all'interno della sessione di un altro utente. Il WindowServer di Mac OS X non è mai stato progettato con questo obiettivo. Le sessioni utente sono estremamente difficili da scappare anche da utente root, il tutto per motivi di sicurezza desiderabili.

Apple ha notevolmente migliorato il design di WindowServer nelle ultime versioni principali di Mac OS X. Ora è possibile avere più utenti connessi a sessioni grafiche diverse su un Mac attraverso la condivisione dello schermo. Questo miglioramento apparentemente semplice si è basato su un enorme sforzo dietro le quinte degli ingegneri Apple.

Tuttavia, è improbabile che Apple fornisca un modo semplice per attraversare le applicazioni di lancio come utenti diversi all'interno di una singola sessione utente grafica. Come andrebbe a vantaggio dei loro clienti?

Se vuoi approfondire questo argomento, cerca le domande che coinvolgono launchctl e le applicazioni in esecuzione in altre sessioni utente attive.

    
risposta data 16.06.2014 - 13:32
fonte
1

Ci sono buone ragioni per NON modificare i file come root. Perché non copiarli in un file temporaneo, modificarli e copiarli.

Potresti usare visudo sebbene ciò richieda una conoscenza di vi , ma è OK per apportare semplici modifiche a /etc/fstab o simili.

Potresti provare ad impostare la variabile d'ambiente EDITOR e ad eseguire visudo anche se non l'ho mai provato con un editor grafico.

    
risposta data 16.06.2014 - 07:00
fonte
0

La risposta di Sergei non ha funzionato per me su OS X 10.8.5

$ sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /etc/hosts

Ho ricevuto un messaggio di errore sulle autorizzazioni

Poiché sudo ha inserito il file binario per primo, quindi facendo doppio clic sul file in Finder ha funzionato, ho trovato il seguente comando meno semplice

$ sudo -b /Applications/TextEdit.app/Contents/MacOS/TextEdit && sleep .5 && open -a /Applications/TextEdit.app /etc/hosts

Puoi farne una funzione come quella di Sergei, se necessario.

    
risposta data 16.06.2015 - 01:16
fonte

Leggi altre domande sui tag