Perché un file con 400 autorizzazioni viene visto scrivibile da root ma di sola lettura da parte dell'utente?

Se creo un file come utente non privilegiato e cambio la modalità di autorizzazione in 400, viene visto da quell'utente come di sola lettura, correttamente:

$ touch somefile
$ chmod 400 somefile
$ [ -w somefile ] && echo rw || echo ro
ro

Tutto bene.

Ma poi arriva root:

# [ -w somefile ] && echo rw || echo ro
rw

Che diamine? Certo, root può scrivere su file di sola lettura, ma non dovrebbe farne l'abitudine: le migliori pratiche tenderebbero a dettare che dovrei essere in grado di testare il bit di permesso di scrittura, e se non lo è, allora è stato impostato in quel modo per un motivo.

Immagino di voler capire sia il motivo per cui ciò sta accadendo, sia come posso ottenere un codice di ritorno falso durante il test di un file che non ha impostato il bit di scrittura?

permissions test readonly

— Ricco
fonte

btw sto usando RHEL6 ( 4.1.2(1)-release) e RHEL7 ( 4.2.46(2)-release).

— Ricco

"Le migliori pratiche tenderebbero a dettare che dovrei essere in grado di testare il bit di permesso di scrittura e, in caso contrario, è stato impostato in quel modo per un motivo." - In realtà, la migliore pratica è "non eseguire roba come root". Se stai eseguendo come root, hai già deciso di ignorare i controlli delle autorizzazioni. La reimplementazione manuale di tali controlli delle autorizzazioni nello spazio utente è una ricetta per il disastro .

— Kevin,

@Kevin Buono per te se riesci a eseguire cose senza privilegi. Questo è per manipolare /etc/dhcp/dhcpd.conf, che è di proprietà di root. Sto usando il fornitore fornito dhcpd. Disastro totale, eh? Il file viene controllato in RCS, sto automatizzando uso di rcsdiff, cie coperché abbiamo operatori che hanno bisogno di ... operare. Il controllo bit di autorizzazione ( -w, come dettagliato da test(1)) sarebbe stata una prima linea di errore, lavorando sulla base che ci -ulascia un file di sola lettura. Lo sto abbandonando e vado subito a rcsdiff -qcontrollare $?. Non disastroso dhcpd? Sarebbe di proprietà di dhcpd.

— Ricco

È un potenziale disastro perché ora hai due diverse implementazioni dei controlli delle autorizzazioni: una nel kernel e una nello spazio utente. Peggio ancora, quelle implementazioni non hanno nemmeno lo scopo di produrre risultati identici, quindi non puoi semplicemente testarle una contro l'altra. Quindi ora hai due percorsi di accesso che devono essere bloccati e protetti indipendentemente l'uno dall'altro.

— Kevin,

@Kevin Certo, non producono risultati identici e non erano previsti (nonostante la scarsità di dettagli nelle manpage), ma voglio esplicitamente controllare il bit di autorizzazione in scrittura ; e le manpage di bashe testmi hanno portato a credere che sia quello che [ -wserve.

— Ricco

Risposte:

test -waka [ -wnon controlla la modalità file. Verifica se è scrivibile. Per root, lo è.

$ help test | grep '\-w'
  -w FILE        True if the file is writable by you.

Il modo in cui vorrei testare sarebbe quello di fare un confronto bit a bit rispetto all'output di stat(1)(" %a Diritti di accesso in ottale").

(( 0$(stat -c %a somefile) & 0200 )) && echo rw || echo ro

Si noti che la subshell $(...)necessita di un 0prefisso in modo che l'output di statsia interpretato come ottale da (( ... )).

— Patrick
fonte

Grazie per essere conciso. Buon uso di (( ... & ... )). È stato corretto un errore di battitura :-)

— Rich

Rendi 3 ... Non ifrichiesto, l'output delle autorizzazioni ottali %anon lo è %de (( ... ))necessita di un prefisso 0per interpretare l'output di statottale.

— Ricco

@Patrick my man statdice "% d numero di dispositivo in decimale", ma ciò che vogliamo sono i "diritti di accesso", no? Il tuo punto sulla necessità del prefisso 0 è ben fatto, ma immagino che dobbiamo solo scartarlo :).

— sourcejedi,

stat -c 0%a...

— sourcejedi,

@sourcejedi ack, hai ragione. Per qualche ragione pensavo che% d fosse un diritto di accesso in decimale. Ripristinata la modifica. grazie :-)

— Patrick

Penso che tu abbia capito male cosa -wfa. Non controlla se il file ha "Autorizzazioni di scrittura", controlla se il file è scrivibile dall'utente che invoca .

Più specificamente, chiama access(2)o simile.

ad esempio se uno script ha if [ -w /etc/shadow ]quindi se si esegue stracesullo script è possibile che venga visualizzata una riga simile a

faccessat(AT_FDCWD, "/etc/shadow", W_OK)

Poiché rootpuò scrivere nel file, restituisce 0.

ad es. come utente normale:

faccessat(AT_FDCWD, "/etc/shadow", W_OK) = -1 EACCES (Permission denied)

Come radice

faccessat(AT_FDCWD, "/etc/shadow", W_OK) = 0

Questo, nonostante il fatto che /etc/shadowabbia il permesso 000sulla mia macchina.

---------- 1 root root 4599 Jan 29 20:08 /etc/shadow

Ora quello che vuoi fare diventa interessante e non è così semplice.

Se si desidera verificare le autorizzazioni semplici, controllare l' lsoutput o chiamare stato simili. Ma renditi conto che gli ACL possono superare queste autorizzazioni. Solo perché un file è permesso 400 non gli impedisce di essere scrivibile ...

— Stephen Harris
fonte

No, "malinteso" significa leggere le pagine man in modo errato per -w: test(1)è esplicito: "FILE esiste e il permesso di scrittura è concesso", non "il file può essere scritto dall'utente corrente ". Nulla di sovrascrivere le autorizzazioni, né ACL. bash(1)è cagey: "Vero se il file esiste ed è scrivibile ." ksh(1)fornisce un sottile suggerimento per gli shenanigans: "-w file // True, se il file esiste ed è scrivibile dal processo corrente ." zsh(1)difende test(1), zshmisc(1)è formulato come ksh(1)e zshexpn(1)specifica alcuni interessanti globbing basati sulle autorizzazioni. csh(1)è esilarantemente breve: "Accesso in scrittura".

btw: ho accettato la risposta di Patrick, 1. perché non hai risposto adeguatamente alla domanda iniziale: come posso ottenere un codice di ritorno falso durante il test di un file che non ha impostato il bit di scrittura? e 2. a causa della presunta anticipazione, ho frainteso le manpage.

— Ricco

@Rich Il modo in cui ho letto questo, penso che anche i tuoi commenti si stiano rivelando un po 'snarky. Non sto dicendo che qualsiasi cosa tu abbia scritto fosse sbagliata, solo che probabilmente sarebbe andata meglio se espressa in modo più educato.

— David Z,

"Penso che tu abbia frainteso ..." non è snarky. La tua risposta, tuttavia, 100% snarky.

— barbecue

@Rich Inoltre, mentre le manpage potrebbero non essere state cristalline, Stephen ha affermato che potresti aver "frainteso ciò che -w fa ", e non quello che dicono le manpage , dove la prima sembra essere il caso, quindi la domanda

— Sebi

L'utente root può fare ciò che desidera, i permessi sui file "normali" non sono una limitazione. Non eseguirà direttamente un file semplice senza alcuna autorizzazione eXecute, solo per un po 'di assicurazione contro la pratica del foot target.

— vonbrand
fonte