Perché un utente non root può eliminare i file creati da root?

Dato un utente non root "joshua", come root ho creato un file chiamato "pippo" nella home directory di joshua (/ home / johsua /); sembra così:

-rw-r--r--  1 root   root       0 12-19 21:00 foo

e quindi eliminarlo come joshua, posso eliminarlo correttamente.

Mi aspetto che joshua non disponga dell'autorizzazione sufficiente per eliminarlo. È una sorta di "eredità delle autorizzazioni"? La mia piattaforma è Debian 5.0.7.

debian

— Giosuè
fonte

1) Questo è fuori tema. 2) Dubito fortemente che tu sia stato in grado di eliminarlo come utente non root senza sudoo altra escalation di privilegi. Probabilmente hai trascurato qualcosa.

— DarkDust,

@DarkDust Un file è una voce nella sua directory padre. Se si dispone dei diritti di scrittura in una directory, è possibile rimuovere i file in essa contenuti indipendentemente da chi possiede i file (a meno che il bit appiccicoso non sia impostato anche sulla directory)

— nn

@nos: sciocco me, hai ragione.

— DarkDust,

Una voce nella sua directory principale è un riferimento a un file. Non è il file stesso. (Altrimenti, come potrebbe un file essere collegato a più di una directory?)

— David Schwartz,

@DavidSchwartz è vero, ma eliminare il file dalla directory significa rimuovere il riferimento nella struttura della directory.

— mc0e

L'utente non ha eliminato il file, lo ha fatto il sistema. L'utente ha semplicemente rimosso il file dalla propria directory. Il sistema ha eliminato il file perché il conteggio dei riferimenti è sceso a zero. È solo un caso che l'utente che ha rimosso il file dalla directory abbia lasciato cadere il suo conteggio di riferimento a zero. (Se il file fosse collegato a un'altra directory o fosse stato aperto un handle al file, non sarebbe stato eliminato.)

Il sistema elimina automaticamente i file quando il loro conteggio dei riferimenti scende a zero. Il proprietario del file non ha importanza. Esistono molti modi in cui un utente diverso dal proprietario di un file può azzerare il conteggio dei riferimenti del file.

La rimozione di un file da una directory (chiamata "unlinking") è un'operazione sulla directory. Scollegare un file riduce il conteggio dei riferimenti.

Allo stesso modo, un utente diverso dal proprietario potrebbe chiudere l'ultimo handle a un file che non è collegato ad alcuna directory. Chiudendo quell'handle si eliminerebbe anche il file, dato che il conteggio dei riferimenti scenderà nuovamente a zero.

— David Schwartz
fonte

E ovviamente il rmcomando confonde un po 'le acque, perché rmè un'abbreviazione di "rimuovi" e gli utenti sono addestrati a pensare rmcome un'operazione di "eliminazione". Molti utenti usano rmogni giorno pur non essendo consapevoli del fatto che l'operazione che esegue effettivamente è un "unlink", non un "elimina". Di conseguenza, non dovrebbe davvero sorprendere che molti utenti trovino sorprendente questo comportamento quando lo incontrano per la prima volta.

— Daniel Pryden,

È sicuramente sorprendente per molte persone. Almeno il rmcomando rimuove infatti un file o una directory da una directory. È peggio su Windows dove viene chiamato il comando del, perché utilizzato per eliminare un file ma su macchine Windows moderne (da NT4), è anche un'operazione di scollegamento.

— David Schwartz,

"L'utente non ha eliminato il file, il sistema ha fatto" Questo non ha senso. Il "sistema" non può apportare modifiche che richiedono un accesso privilegiato per conto dell'utente non privilegiato. Pertanto, questa risposta non spiegherà perché lo stesso utente non può fare lo stesso se la directory corrente era di proprietà + scrivibile solo da root. La risposta di seguito di @kerrek è precisa e concisa.

— FractalSpace

@FractalSpace Huh? Il sistema può apportare modifiche che richiedono un accesso privilegiato per conto di un utente non privilegiato e lo fa sempre. Ad esempio, la modifica dei byte su un disco richiede un accesso privilegiato. Tuttavia, se un utente può modificare un file, il sistema deciderà di modificare alcuni byte sul disco anche se l'utente non dispone dell'autorizzazione per modificare tali byte. Un utente non può modificare la memoria del kernel, ma il kernel può eseguirlo per conto di un utente. I sistemi funzionano decidendo di eseguire operazioni che i loro utenti non possono autorizzare direttamente.

— David Schwartz,

Sì. E alla fine tutto viene fatto dal "sistema". Ma non prima di passare attraverso rigide regole di separazione dei privilegi stabilite per quel particolare "spazio utente". In questo scenario, ad esempio, "sistema" non sta eseguendo un'azione come regola generale, ma sta seguendo le autorizzazioni impostate sulla "directory padre". La parte fondamentale di questo problema nella domanda OP.

— FractalSpace,

Prima ipotesi: per eliminare un file è necessario disporre delle autorizzazioni di scrittura per la cartella contenente. Quindi prova / home / johsua / foo / bar, dai 755 a foo e 644 a bar.

— Eugen Rieck
fonte