Concede il privilegio sudo non amministratore, ma con '~' è la sua casa ~

3

Ho sentito dire che, con l'idea generale di privilegio minimo, gli utenti di tipo Unix dovrebbero creare un altro account senza privilegio sudo, oltre all'account incorporato con privilegio sudo. In Mac, questo si traduce in: si dovrebbe creare un account personale per l'uso quotidiano, oltre all'account amministratore fornito con il computer, riservato solo quando necessario.

Per concretezza, diciamo che bruce è uno staff, che uso quotidianamente e batman è un admin, che uso solo quando necessario. Ma come posso, mentre eseguo il login in batman , eseguire attività sudo, per conto di bruce , vale a dire con bruce proprio ~ e $(whoami) proprio come se fossi loggato in bruce con privilegio?

Per illustrare questo, definisci /User/bruce/test.sh :

#!/usr/bin/env bash

whoami
cd ~ && pwd
ls ~/Library/Preferences/Preferences/

(Sì, ho fatto chmod 744 test.sh ) Ho scelto l'ultima riga per scopi di illustrazione artificiale che, normalmente, ~/Library/Preferences/Preferences/ non è accessibile a uno staff (vale a dire un non amministratore).

Quello che intendo ricevere è bruce , /Users/bruce e riuscito ls output.

Il primo tentativo è, in effetti, se apro il terminale di bruce , ma login il bash di batman (per ottenere il privilegio di sudo), ed esegui

sudo /Users/bruce/test.sh

Ottengo root , /Users/batman e riuscito ls output di ~/Library/Preferences/Preferences/ , a dimostrazione che la casa è batman; non c'è da meravigliarsi

Oppure, un possibile duplicato (a) asserisce che sudo -i -u bruce mi consente di eseguire comandi come bruce . Ma no! Se I (come sopra) apre il terminale di bruce , login il bash di batman , ed esegui

sudo -i -u bruce /Users/bruce/test.sh

Ottengo bruce , /Users/bruce e ls: : Permission denied .

Ancora un altro possibile duplicato (b) afferma che sudo -H -u bruce utilizza la casa di bruce. Bene, di nuovo quando apro il terminale di bruce , login il bash di batman , ed eseguo

sudo -H -u bruce bash /Users/bruce/test.sh

Anche io ottengo bruce , /Users/bruce e ls: : Permission denied .

Il lettore potrebbe pensare che la mia richiesta non sia ragionevole; ma voglio solo sapere se è possibile concedere temporaneamente privilegio sudo a uno staff, il che può essere conveniente a volte. Ad esempio, se questo può essere fatto, quando sto facendo un breve script non ho più bisogno di evitare $(whoami) o ~ , rendendolo più flessibile. Oppure, quando eseguo un breve script, quale sito suggerisco, né devo sostituire $(whoami) di bruce e / o ~ di /Users/bruce .

L'ultima volta, per quanto ricordo, sono stato irritato dalla limitazione dei privilegi, è probabilmente quando ho eseguito una sceneggiatura scritta su disco che ho cercato su google, al fine di installare un font LaTeX.

Tuttavia, al momento posso ricordare solo un'istanza. Cioè, dopo che I, durante l'accesso a batman, brew -ed qualcosa usando homebrew (perché richiede sudo privilegio), e logout -ed indietro come bruce e brew -ed qualcosa di altro. Homebrew ha lamentato un numero elevato di autorizzazioni errate di alcune cartelle in /usr/local e mi ha spinto a eseguire sudo chown -R $(whoami) blablabla . Mi è sembrato che brew avesse impostato un determinato permesso su batman e mi ha fatto impazzire a correggerli uno per uno.

Che cosa fai per aggirare il momento, ad esempio, che brew richiede sudo, mentre usi un account dello staff? O, dopo tutto, è la pratica che l'account usato quotidianamente dovrebbe contenere privilegi minimi, semplicemente irrealistici?

    
posta Aminopterin 27.11.2016 - 10:22
fonte

1 risposta

2

C'è probabilmente un difetto nella cartella home di bruce: le autorizzazioni di ~ / Library / Preferences / Preferences sono sbagliate. Pertanto lo script non funziona come previsto.

Controlla il seguente output nel mio ambiente eseguendo lo script registrato come amministratore. Ho leggermente modificato lo script e sostituito ls ~/Library/Preferences/Preferences di ls -la ~/Library/Preferences | grep "loginwindow"

/Users/bruce/bin/sh/test-env.sh
batman
/Users/batman
-rw-------    1 batman  staff     192 27 Nov 13:42 com.apple.loginwindow.plist
-rw-------    1 batman  staff     198 24 Okt 21:43 loginwindow.plist

sudo /Users/bruce/bin/sh/test-env.sh
root
/Users/batman
-rw-------    1 batman  staff     192 27 Nov 13:42 com.apple.loginwindow.plist
-rw-------    1 batman  staff     198 24 Okt 21:43 loginwindow.plist

sudo -i -u bruce /Users/bruce/bin/sh/test-env.sh
bruce
/Users/bruce
-rw-------    1 bruce  staff      95 27 Nov 13:40 com.apple.loginwindow.plist
-rw-------    1 bruce  staff     198 27 Nov 13:36 loginwindow.plist

sudo su bruce
/Users/bruce/bin/sh/test-env.sh
bruce
/Users/bruce
-rw-------    1 bruce  staff      95 27 Nov 13:40 com.apple.loginwindow.plist
-rw-------    1 bruce  staff     198 27 Nov 13:36 loginwindow.plist
$USERNAME = root #check this by entering 'env' in the shell additionally

sudo su -l bruce
/Users/bruce/bin/sh/test-env.sh
bruce
/Users/bruce
-rw-------    1 bruce  staff      95 27 Nov 13:40 com.apple.loginwindow.plist
-rw-------    1 bruce  staff     198 27 Nov 13:36 loginwindow.plist
$USERNAME = <empty>

Inoltre: c'è un grosso malinteso su come funziona davvero sudo / su. Il tuo amministratore batman mai esegue un comando "per conto" di un altro utente. Se inserisci "sudo some_command" o "sudo -i -u utente some_command" è sempre la posizione elevata del superutente (e il privilegio di un amministratore di eseguire sudo come determinato dal file sudoers e "rendersi superutente" temporaneamente) "esegue correttamente il comando per conto di un altro utente".

Se devi eseguire comandi con privilegi escalation su base giornaliera con l'utente non amministratore, aggiungilo al file sudoers e aggiungi solo un numero limitato di comandi.

Esempio (controllo del server Web Apache):

bruce ALL=(ALL) /usr/sbin/apachectl

o senza l'obbligo di inserire una password dopo l'esecuzione di sudo apachectl come bruce:

bruce ALL=(ALL) NOPASSWD: /usr/sbin/apachectl

O modifica gli script in modo appropriato per rimanere nel regno di bruce.

Ciò detto il consiglio / pratica che "l'utente quotidiano non dovrebbe essere un sudoer" è ancora valido.

Homebrew è una bestia diversa: è progettata per essere installata da un solo utente, un utente amministratore. La maggior parte delle app / eseguibili fornite dall'ambiente homebrew possono essere lanciate da un utente standard dopo aver modificato il PATH $ dell'utente o utilizzando il percorso completo.

Esistono diversi modi per configurare homebrew come ambiente multiutente (ad es. My Homebrew Multi User Setup ). Non so se questo si applica ancora ai nuovi sistemi OS X / versioni di brew.

    
risposta data 27.11.2016 - 19:24
fonte

Leggi altre domande sui tag