Come rimuovere una directory non vuota che non è di proprietà dell'utente in Linux?


10

Se una directory "foo" è di proprietà dell'utente A e contiene una directory "bar", che è di proprietà di root, l'utente A può semplicemente rimuoverla con rmdir, il che è logico, perché "foo" è scrivibile dall'utente A.

Ma se la directory "bar" contiene un altro file di proprietà di root, la directory non può essere rimossa, perché i file in essa contenuti devono essere rimossi per primi, quindi diventa vuota. Ma "bar" in sé non è scrivibile, quindi non è possibile rimuovere i file al suo interno.

C'è un modo per aggirarlo? Oppure, convincimi altrimenti perché è necessario.

Risposte:


7

Interpretazione 1: una directory è un sottospazio del filesystem. Può essere ulteriormente suddiviso in sottospazi creando in esso sottodirectory. Il proprietario della directory foodovrebbe avere il controllo su tutto all'interno del sottospazio: foo/bar, foo/bar/qux, etc.

Interpretazione 2: una directory è un sottospazio del filesystem. Ogni directory è collegata a qualche altra directory, chiamata il suo genitore. Il proprietario della directory fooha il controllo su tutto all'interno del sottospazio; tuttavia, per una sottodirectory foo/bar, il proprietario di fooha il controllo su se barpuò essere collegato fooma non su ciò che accade all'interno bar: solo il proprietario di barha il controllo su quello.

Prove a favore dell'interpretazione 2: come hai notato, il modo in cui funzionano le autorizzazioni. Inoltre, il fatto che alcuni filesystem Unix consentano di associare una directory a più di un genitore: questo si chiama con più collegamenti fissi. (Avere più collegamenti fissi è comune per i file regolari, ma di solito è scoraggiato o vietato per le directory principalmente a causa del rischio di creare loop, in cui una directory viene rimossa dal proprio nonno N volte, quindi non è possibile accedervi dalla radice directory, che è un'aspettativa molto comune. C'è anche il problema di cosa fare se una directory ha 0 hard link ma non è vuota: poiché la directory non è collegata, si desidera eliminarla, ma cosa si fa con la sua Contenuti?)

Prove a favore dell'interpretazione 1: in pratica, le directory hanno un genitore single e quindi formano una struttura ad albero. E non puoi accedere a foo/bar/quxmeno che tu non abbia eseguito il permesso fooe anche bar(beh, tranne per il fatto che ci sono modi in qualche modo oscuri di avere accesso barsenza averne accesso foo). Quindi i livelli superiori contano.

Su una nota più pratica, nella tua situazione, l'utente A può fare

immondizia mkdir
mv foo / bar garbage /
rmdir foo

1
Questa è un'ottima risposta (rec'notata), ma l'apparente incoerenza rimane frustrante per me. E mentre l'esempio pratico di spostare la barra in Garbage funziona, ci rimane una directory chiamata garbage che non può essere rimossa. Ho lo stesso problema, tranne per il fatto che è l'utente A e l'utente B, in cui B ha bloccato qualcosa in una directory di proprietà di A, che A vuole rimuovere.
Paul Hooper,

Questa è una buona spiegazione, ma l'esempio usato mvalla fine per aggirare il problema non funziona per me su Raspbian (non ho provato su nessun altro sistema). Inoltre, dopo aver studiato questo problema, non ho visto l'uso di mvcome soluzione menzionata altrove. In effetti, in base alla mia comprensione di come funzionano le autorizzazioni, ha senso che mvfallisca quando l'ho provato. Mi sto perdendo qualcosa? O questa funzionalità è forse cambiata? @Gilles @PaulHooper
fvgs

@fvgs Non è cambiato nulla, ma la tua situazione potrebbe avere autorizzazioni diverse da questa. Ti suggerisco di porre una nuova domanda (su Unix e Linux anziché su Server Fault poiché questa domanda sarebbe probabilmente considerata fuori tema se fosse stata posta su SF ora) e fornire tutti i dettagli della tua situazione.
Gilles 'SO- smetti di essere malvagio' il

@Gilles Potresti indicarmi un po 'di documentazione, riferimento o menzione del comportamento descritto per mv? Sono in grado di utilizzare mvper rinominare la directory della barra. Ciò significa che l'operazione mvriesce finché non provo a spostare la barra all'esterno della directory corrente o in qualsiasi altra directory. Ma l'esempio che hai dato (che sposta la barra in una directory) non funziona per me (permesso negato). L'esempio che hai fornito presuppone condizioni specifiche diverse da quelle specificate nella domanda?
fvgs,

@fvgs Il mio esempio non sposta baruna directory in alto, ma la sposta in una directory di tua proprietà. garbagepuò trovarsi ovunque sullo stesso filesystem, non necessariamente un fratello di foo.
Gilles 'SO- smetti di essere malvagio' il

0

L'unico modo per aggirare questo sarebbe usare un setgid o un setuid nella directory padre o usare un ACL.

Impostare la directory setgid con

chmod g+s foo

Impostare un ACL predefinito su di esso con

setfacl -d -R -m g:group:rwx foo

Questo lo imposta come ACL predefinito su questo percorso. Devi montare il filesystem che contiene questo percorso con l'opzione acl!

Ora dimmi perché pensi di volerlo.


Bene, il problema è di coerenza. Nulla mi impedisce di eliminare un file o una directory vuota di proprietà di un altro utente in una directory di mia proprietà, ma se non è vuota, sono bloccato dall'eliminazione della mia directory.
Alex B,

In tal caso, utilizzerei una delle opzioni fornite. Funzioneranno bene per te.
wzzrd,

Uso spesso più account sul mio desktop (uno dei quali è l'account "principale non root"). Posso anche ottenere una situazione del genere quando make installavviato da root inizia a costruire qualcosa.
Vi.

setgid nella directory principale non aiuta. Dopo aver fatto come root cd ~user && mkdir qqq && touch qqq/qqqnon riesco a liberarmi di qqq dall'utente di chmod g+s .e rm -Rf qqq.
Vi.

Mmh. Questa è probabilmente una questione umask allora. Se la tua directory è 775, è setgid e umask è 0002, i file sono scrivibili per il gruppo e quindi rimovibili per te. Ma, vero, non funziona con umask 0022 (che è principalmente il valore predefinito). Avrei dovuto dirlo. Hai testato l'opzione acl?
wzzrd,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.