Comment supprimer un répertoire non vide qui n'appartient pas à l'utilisateur sous Linux?

Si un répertoire "foo" appartient à l'utilisateur A et contient un répertoire "bar", qui appartient à root, l'utilisateur A peut simplement le supprimer avec rmdir, ce qui est logique, car "foo" est accessible en écriture par l'utilisateur A.

Mais si le répertoire "bar" contient un autre fichier appartenant à root, le répertoire ne peut pas être supprimé, car les fichiers qu'il contient doivent être supprimés en premier, il devient donc vide. Mais "bar" lui-même n'est pas accessible en écriture, il n'est donc pas possible de supprimer des fichiers qu'il contient.

Y a-t-il un moyen de contourner cela? Ou, convainquez-moi autrement pourquoi c'est nécessaire.

linux permissions

— Alex B
source

Réponses:

Interprétation 1: un répertoire est un sous-espace du système de fichiers. Il peut être subdivisé en sous-espaces en y créant des sous-répertoires. Le propriétaire du répertoire foodevrait avoir le contrôle sur tout l' intérieur du sous - espace: foo/bar, foo/bar/qux, etc.

Interprétation 2: un répertoire est un sous-espace du système de fichiers. Chaque répertoire est attaché à un autre répertoire, appelé son parent. Le propriétaire du répertoire foocontrôle tout ce qui se trouve dans le sous-espace; cependant, pour un sous-répertoire foo/bar, le propriétaire de fooa le contrôle sur la possibilité de barl'attacher foomais pas sur ce qui se trouve à l'intérieur bar: seul le propriétaire de le barcontrôle.

Preuve en faveur de l'interprétation 2: comme vous l'avez noté, le fonctionnement des autorisations. De plus, le fait que certains systèmes de fichiers Unix permettent d'attacher un répertoire à plusieurs parents: cela s'appelle avoir plusieurs liens durs. (Avoir plusieurs liens durs est courant pour les fichiers normaux, mais c'est généralement déconseillé ou interdit pour les répertoires principalement en raison du risque de créer des boucles, où un répertoire est son propre grand-parent N fois supprimé - vous ne pouvez donc pas y accéder depuis la racine répertoire, qui est une attente très courante. Il y a aussi le problème de ce qu'il faut faire si un répertoire a 0 liens durs mais n'est pas vide: puisque le répertoire n'est pas attaché, vous voudriez le supprimer, mais que faites-vous avec son Contenu?)

Preuve en faveur de l'interprétation 1: dans la pratique, les répertoires ont un seul parent et forment donc une structure arborescente. Et vous ne pouvez pas accéder à foo/bar/quxmoins que vous avez l' autorisation d' exécution sur fooainsi que bar(bien, sauf qu'il existe des moyens quelque peu obscures à donner accès à barsans être donné à l' accès foo). Les niveaux supérieurs importent donc.

Sur une note plus pratique, dans votre situation, l'utilisateur A peut faire

ordures mkdir
mv foo / bar poubelle /
rmdir foo

— Gilles 'SO- arrête d'être méchant'
source

C'est une excellente réponse (rec'ed), mais l'incohérence apparente reste frustrante pour moi. Et bien que l'exemple pratique de déplacer la barre vers les ordures fonctionne, nous nous retrouvons avec un répertoire appelé ordures qui ne peut pas être supprimé. J'ai ce même problème, sauf que ce sont les utilisateurs A et B, où B a collé quelque chose dans un répertoire appartenant à A, que A veut supprimer.

— Paul Hooper

C'est une bonne explication, mais l'exemple à la fin en utilisant mvpour contourner le problème ne fonctionne pas pour moi sur Raspbian (je n'ai essayé sur aucun autre système). De plus, après avoir étudié ce problème, je n'ai vu l'utilisation de mvcomme solution mentionnée nulle part ailleurs. En effet, d'après ma compréhension du fonctionnement des autorisations, il est logique que le mvéchoue lorsque je l'ai tenté. Suis-je en train de manquer quelque chose? Ou cette fonctionnalité a-t-elle peut-être changé? @Gilles @PaulHooper

— fvgs

@fvgs Rien n'a changé, mais votre situation peut avoir des autorisations différentes de celle-ci. Je suggère que vous posiez une nouvelle question (sur Unix et Linux plutôt que sur Server Fault car cette question serait probablement considérée comme hors sujet si elle était posée sur SF maintenant) et donnez tous les détails de votre situation.

— Gilles 'SO- arrête d'être méchant'

@Gilles Pourriez-vous s'il vous plaît m'indiquer une documentation, une référence ou une mention du comportement pour lequel vous avez décrit mv? Je peux utiliser mvpour renommer le répertoire des barres. Cela signifie que le mvréussit tant que je n'essaie pas de déplacer la barre en dehors du répertoire actuel ou dans un autre répertoire. Mais l'exemple que vous avez donné (qui déplace la barre vers le haut d'un répertoire) ne fonctionne pas pour moi (autorisation refusée). L'exemple que vous avez donné suppose-t-il des conditions spécifiques autres que celles spécifiées dans la question?

— fvgs

@fvgs Mon exemple ne barmonte pas dans un répertoire, il le déplace dans un répertoire qui vous appartient. garbagepeut être n'importe où sur le même système de fichiers, pas nécessairement un frère de foo.

— Gilles 'SO- arrête d'être méchant'

Le seul moyen de contourner ce problème serait d'utiliser soit un setgid soit un setuid sur le répertoire parent ou d'utiliser une ACL.

Définissez le répertoire setgid avec

chmod g+s foo

Définissez une ACL par défaut dessus avec

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

Cela le définit comme l'ACL par défaut sur ce chemin. Vous devez monter le système de fichiers qui contient ce chemin avec l'option acl!

Maintenant, dites-moi pourquoi vous pensez que vous voulez cela.

— wzzrd
source

Eh bien, le problème est celui de la cohérence. Rien ne m'empêche de supprimer un fichier ou un répertoire vide appartenant à un autre utilisateur dans un répertoire que je possède, mais s'il n'est pas vide, je ne peux pas supprimer mon propre répertoire.

— Alex B

Si tel est le cas, j'utiliserais l'une des options que j'ai fournies. Ils fonctionneront bien pour vous.

— wzzrd

J'utilise souvent plusieurs comptes sur mon bureau (dont l'un est le compte "principal non root"). Je peux également obtenir une telle situation lorsque make installdémarré à partir de la racine commence à construire quelque chose.

— Vi.

setgid sur le répertoire parent n'aide pas. Après avoir fait en tant que root, cd ~user && mkdir qqq && touch qqq/qqqje ne peux pas me débarrasser de qqq de l'utilisateur par chmod g+s .et rm -Rf qqq.

— Vi.

Mmh. C'est probablement une question umask alors. Si votre répertoire est 775, il est setgid et votre umask est 0002, alors les fichiers sont accessibles en écriture pour le groupe et donc amovibles pour vous. Mais, vrai, cela ne fonctionne pas avec umask 0022 (qui est principalement la valeur par défaut). J'aurais dû dire ça. Avez-vous testé l'option acl?

— wzzrd