Trovare file che un utente non può leggere?

Voglio trovare i file che un determinato utente non sarà in grado di leggere.

Supponiamo che il nome utente sia "user123" e che siano in un gruppo chiamato "user123". Voglio trovare i file che, se sono di proprietà di user123, hanno u+r su; in caso contrario, se il file è di gruppo user123 dovrebbe avere g+r acceso; in mancanza può avere o+o acceso.

Dal momento che GNU find ha "-leggibile", potrei fare questo:

sudo -u user123 find /start ! -readable -ls

Tuttavia, il processo deve essere eseguito da un utente che non dispone dell'accesso sudo. Quindi ho provato questo:(non spunta o+r ma non è importante a questo punto)

find /start ( -user user123 ! -perm -u=r  ) -o ( -group user123 ! -perm -g=r  ) -ls

ma elenca questo file:

272118    4 -rw-------   1 user123   user123       3243 Jul  3 19:50 /start/blah/blah/file.txt

Questo file è l'unico file sotto /start che è di proprietà dell'utente123 con g=r spento. È come se find interpretasse il -u=r come -g=r .

Ho deciso di provare a invertire la logica e testare invece not ( truth ) invece:

find /etc/puppet ! ( ( -user puppet -perm -u=r  ) -o ( -group puppet -perm -g=r ) -o ( -perm -o=r ) )  -ls

Funziona!

Perché l'originale find fallire? È un bug in find (improbabile) o la logica è sbagliata?

Aggiornamento: Ho sbagliato logica. Come sottolineato di seguito, poiché
! ( A || B || C ) ==( !A &&!B &&!C )
queste sono le due affermazioni equivalenti:

find /start ! ( ( -user user123 -perm -u=r ) -o ( -group user123 -perm -g=r ) -o ( ! ( -user user123 -o -group user123 ) -perm -o=r ) ) -ls
find /start ! ( -user user123 -perm -u=r ) ! ( -group user123 -perm -g=r ) ! ( ! ( -user user123 -o -group user123 ) -perm -o=r ) -ls

Il mio obiettivo era non dover testare due volte utente/gruppo. Quello di cui ho veramente bisogno è una struttura if-then-else più complicata, che sarebbe probabilmente possibile solo se ci fosse un operatore -xor. Potrei costruire uno xor da e/o/non, ma sarebbe più complesso delle due soluzioni precedenti.

Risposta accettata:

La logica è sbagliata. Stai pensando che questo file non avrebbe dovuto essere elencato perché è di proprietà di user123 e ha il r dell'utente bit impostato. Tuttavia, è elencato perché corrisponde al secondo criterio (è di proprietà del gruppo user123 e ha il r del gruppo bit non impostato).

La tua seconda versione funziona grazie a una delle leggi di de Morgan:negare l'ORing logico di un gruppo di affermazioni è logicamente equivalente ad ANDare la negazione delle singole affermazioni. In altre parole:

 ! ( A || B || C ) == ( !A && !B && !C )

Quindi il lavoro find sta cercando un file che

• Non è (di proprietà dell'utente user123 e leggibile da detto utente) E
• Non è (di proprietà del gruppo user123 e leggibile da detto gruppo) E
• Non è leggibile dal mondo intero.

Correlati:Linux – Dato un hash di commit git, come scoprire quale versione del kernel lo contiene?

mentre il primo find sta cercando un file che

• È di proprietà dell'utente user123 e non leggibile da detto utente O
• È di proprietà del gruppo user123 e non leggibile da detto gruppo OPPURE (se l'avevi compilato)
• Non è leggibile dal mondo intero

Quindi un file che corrisponde a QUALSIASI dei 3 criteri sopra (e non necessariamente a tutti) verrebbe elencato come hai visto.

Modifica

Per inciso (dopo aver visualizzato il tuo profilo), sono un grande fan del tuo libro O'Reilly 🙂