Come funzionano le autorizzazioni dei file per l'utente "root"?

Ho il seguente file:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Ho commutato l'utente rootnel terminale e ho notato i seguenti comportamenti:

• Posso leggere questo file e scrivergli.

• Non riesco a eseguire questo file.

• Se imposto il xbit nelle autorizzazioni utente ( ---x------) o nelle autorizzazioni di gruppo ( ------x---) o nelle altre autorizzazioni ( ---------x) del file, allora sarei in grado di eseguire questo file.

Qualcuno può spiegarmi o indicarmi un tutorial che spiega tutte le regole che si applicano quando l' rootutente ha a che fare con file e directory?

L'accesso privilegiato a file e directory è in realtà determinato dalle capacità, non solo dall'essere rooto meno. In pratica, di rootsolito ha tutte le possibilità possibili, ma ci sono situazioni in cui tutti / molti di essi potrebbero essere eliminati o alcuni dati ad altri utenti (i loro processi).

In breve, hai già descritto come funzionano i controlli di controllo dell'accesso per un processo privilegiato. Ecco come le diverse funzionalità la influenzano effettivamente:

La capacitàCAP_DAC_OVERRIDE principale qui è , un processo che lo ha può "bypassare la lettura, la scrittura e l'esecuzione dei controlli delle autorizzazioni". Ciò include la lettura e la scrittura su qualsiasi file, nonché la lettura, la scrittura e l'accesso alle directory.

In realtà non si applica all'esecuzione di file che non sono contrassegnati come eseguibili. Il commento trageneric_permission ( fs/namei.c), prima che l'accesso controlli i file, dice questo

I DAC di lettura / scrittura sono sempre ignorabili. I DAC eseguibili sono sostituibili quando è impostato almeno un bit di exec.

E il codice verifica che sia ximpostato almeno un bit se si sta tentando di eseguire il file. Sospetto che sia solo una funzione utile, per impedire l'esecuzione accidentale di file di dati casuali e ottenere errori o risultati strani.

Ad ogni modo, se puoi sovrascrivere le autorizzazioni, potresti semplicemente fare una copia eseguibile ed eseguirla. _{(Anche se potrebbe fare una differenza in teoria per i file setuid di un processo è stato in grado di sovrascrivere i permessi dei file ( CAP_DAC_OVERRIDE), ma non aveva altre capacità correlate ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Ma avendo permesso l' CAP_DAC_OVERRIDEediting /etc/shadowe cose del genere, quindi è approssimativamente uguale ad avere comunque l'accesso completo alla radice.)}

C'è anche la CAP_DAC_READ_SEARCHcapacità che consente di leggere qualsiasi file e accedere a qualsiasi directory, ma di non eseguirli o scriverli; e CAP_FOWNERciò consente a un processo di fare cose che di solito sono riservate solo al proprietario del file, come la modifica dei bit di autorizzazione e del gruppo di file.

L'override della parte adesiva delle directory è menzionata solo sotto CAP_FOWNER, quindi sembra che CAP_DAC_OVERRIDEnon basterebbe ignorarlo. (Ti darebbe il permesso di scrivere, ma di solito in directory appiccicose lo hai comunque e lo +tlimita.)

_{(Penso che i dispositivi speciali contino come "file" qui. Almeno generic_permission()ha un controllo del tipo per le directory, ma non ho controllato al di fuori di questo.)}

Naturalmente, ci sono ancora situazioni in cui anche le funzionalità non ti aiuteranno a modificare i file:

• alcuni file in /proce /sys, dato che non sono file reali
• SELinux e altri moduli di sicurezza che potrebbero limitare root
• chattrimmutabile +ie aggiungi solo +aflag su ext2 / ext3 / ext4, entrambi i quali fermano anche il root e impediscono anche la ridenominazione dei file, ecc.
• filesystem di rete, in cui il server può eseguire il proprio controllo di accesso, ad esempio root_squashnelle mappe NFS root a nessuno
• FUSE, che presumo possa fare qualsiasi cosa
• supporti di sola lettura
• dispositivi di sola lettura

È esattamente come hai notato per le autorizzazioni predefinite:

• Lettura e scrittura:
  per impostazione predefinita, l'utente root può accedere a qualsiasi file nel sistema. È possibile rimuovere questo accesso modificando gli attributi come spiegato qui: chattr . Questo è quindi collegato alle funzionalità.

• Esegui: l'
  utente root non dispone dell'autorizzazione di esecuzione a meno che non sia impostato almeno uno dei bit di esecuzione.

Il myFile.txtè ottenuto da chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- significa che non esiste alcun permesso per utente, gruppo e altro.

L'utente root ha una capacità illimitata di modificare questo file. La lettura / scrittura è garantita. Per eseguire questo file l'utente root deve renderlo comunque eseguibile. (chmod 100, 010 o 001)

La modalità di esecuzione viene trattata in modo leggermente diverso dalle altre modalità.

Le autorizzazioni di lettura e scrittura vengono utilizzate per applicare le politiche di sicurezza. L' rootutente è generalmente immune dalle restrizioni di sicurezza (ci sono alcune eccezioni, come i file immutabili, e le funzionalità moderne come le capacità hanno reso questo più preciso), motivo per cui un altro nome per questo account è il "superutente".

Permesso di esecuzione è più di una funzione consultiva, distinguendo se il file è destinato ad essere eseguibile o è solo dati. Per questo motivo, anche l'utente root lo obbedisce: non ha senso eseguire un file di dati. Se nessuna delle autorizzazioni di esecuzione è impostata, root non può eseguire il file; se qualcuno di questi è impostato, può farlo. Naturalmente, poiché root ha anche l'autorizzazione per modificare le autorizzazioni di qualsiasi file, l'account può rendere eseguibile un file se lo desidera (a meno che il filesystem non sia di sola lettura).

A proposito, gli script sono un caso interessante in questo. Gli script sono file di dati per l'interprete rilevante. Se lo script ha una #!riga, è possibile eseguirlo come programma: l'interprete denominato nello shebang viene eseguito con il nome del file di script come argomento. Ma questo verrà fatto solo quando è impostata l'autorizzazione di esecuzione. D'altra parte, puoi semplicemente eseguire direttamente l'interprete, ad es /bin/bash scriptname. Gli interpreti si preoccupano solo di poter leggere il file, non controllano le autorizzazioni di esecuzione.

Lascia che ti spieghi teoricamente.

l'utente root è il re del sistema operativo.

Se un file o una directory hanno autorizzazioni come X per l'esecuzione ma nient'altro e qualcuno come l'utente Steve possiede il file, anche root può eseguire il file.

Ricorda sempre, in Linux root può fare qualsiasi cosa, non ci sono restrizioni su root.