J'ai un rêve depuis pas mal d'années: avoir des ACLs sous Linux aussi bonnes que sous Windows (oui, les ACLs NTFS de Windows sont presques très bien, pas celle de Linux, loin de là).
Aujourd'hui encore je tombe sur un cas qui fonctionne parfaitement bien avec Windows, facilement, toussa. Et impossible d'avoir à peu près la même chose sous Linux.
J'écris cela ici dans l'espoir que je sois juste un gros mauvais, et qu'on me clou le bec en me disant "il suffit de taper setfacl xxxxxx toto titi". Je serais bien content de constater être un gros nul, si vous saviez comme ça me faciliterait le travail :-)
Assez palabré, voici le cas:
répertoire--+
............|
............+---
Forum Linux.général ACLs à la Windows
28
juin
2010
# Zut, j'ai validé... :-)
Posté par Kerro . Évalué à 4.
répertoire--+
............|
............+---utilisateur1
............|
............+---utilisateur2
............|
............+---groupe1
............|
............+---groupe2
"répertoire" est accessible en lecture/écriture/modification par tous les utilisateurs (ici via Samba).
Chaque sous répertoire est protégé. Par exemple "utilisateur1" n'est accessible qu'à, devinez, l'utilisateur nommé utilisateur1.
"groupe1" n'est accessible qu'à une liste de personne.
Jusque là c'est facile. Il suffit d'utiliser setfacl ou smbcacls pour ajouter des droits.
Avec Windows, il est possible de supprimer explicitement des droits. Par exemple j'indique que "tout le monde" n'a pas le droit de supprime le répertoire "utilisateur1". Sous Linux, pas possible.
Ce qui fait que n'importe qui pouvant modifier "répertoire" est également capable d'effacer les sous-répertoires.
Je sais d'avance que certains vont répondre "y'a qu'à interdire l'écriture dans le répertoire de base". Ce qui complique beaucoup la tâche pour les utilisateurs qui veulent par exemple bosser à plusieurs dans "compta" _et_ avoir certains sous-répertoires confidentiels, ou simplement protégés contre les erreurs. Si ils ne peuvent pas le faire ainsi, c'est à l'administrateur de créer à chaque fois un répertoire à partir de la racine du partage.
D'où question: une astuce pour contourner cette limitation ?
[^] # Re: Zut, j'ai validé... :-)
Posté par Frédéric Perrin (site web personnel) . Évalué à 9.
In addition to the three sets of three permissions listed above, a
file's permissions have three special components, which affect only
executable files (programs) and, on some systems, directories:
[...]
3. prevent users from removing or renaming a file in a directory
unless they own the file or the directory; this is called the
"restricted deletion flag" for the directory. For regular files
on some systems, save the program's text image on the swap device
so it will load more quickly when run; this is called the "sticky
bit".
[^] # Re: Zut, j'ai validé... :-)
Posté par Frédéric Perrin (site web personnel) . Évalué à 4.
Tu es juste un gros mauvais. Il suffit de taper chmod 04777 comp/. Gros nul, on te facilite le travail !
:-)
[^] # Re: Zut, j'ai validé... :-)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
1. Les permissions, c'est sur 4 chiffres octaux, pas 5.
2. Le sticky bit, c'est 1 sur le premier chiffre, pas 4.
Donc plutôt :
chmod 1777 comp/Ou plus exactement, pour éviter de toucher aux permissions existantes :
chmod +t comp[^] # Re: Zut, j'ai validé... :-)
Posté par Frédéric Perrin (site web personnel) . Évalué à 4.
Le premier zéro est le préfixe usuel pour indiquer les nombres en base 8. Inutile pour l'argument à chmod, c'est vrai, mais par habitude...
Le sticky bit, c'est 1 sur le premier chiffre, pas 4.
Autant pour moi, je me suis fait avoir par la position du sticky bit dans la liste, je les croyais rangé par ordre de puissance de 2, sans avoir vérifié. L'écriture symbolique est aussi simple.
[^] # Re: Zut, j'ai validé... :-)
Posté par Obsidian . Évalué à 4.
« Au temps pour moi ».
Mais c'est vrai que je me suis souvent trompé de chiffre pour le sticky, moi aussi.
[^] # Re: Zut, j'ai validé... :-)
Posté par Kerro . Évalué à 3.
[^] # Re: Zut, j'ai validé... :-)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
1. Tu veux que tes utilisateurs puissent créer des fichiers (en l'occurrence, des répertoires) eux-mêmes, sans te demander. Donc un répertoire racine où ils peuvent écrire.
2. Tu veux que n'importe quel utilisateur ne puisse pas retirer un fichier d'un autre (en l'occurrence, un répertoire). Donc un répertoire racine sticky.
3. Tu veux que tes utilisateurs puissent créer des sous-répertoires avec une liste précise de gens ayant le droit de faire ceci ou cela. C'est là que ça coince, parce que ça contredit le point 1 : ce sont des utilisateurs, et ça, ils ne le feront pas eux-mêmes. Ils te demanderont de le créer, le répertoire de la mort.
Donc, mon conseil : réfléchis à ton besoin. Si tu as un répertoire /compta (je compte à partir de la racine du partage), écrire dedans, cela signifie organiser le classement même des données de la compta : c'est un droit qui devrait revenir aux chefs de la compta. Si tu as un répertoire /compta/planning, écrire dedans signifie organiser le planning de la compta, à toi de voir qui est censé le faire. Mais quelqu'un qui a le droit d'organiser le classement de la compta pourra supprimer ce répertoire (s'il est vide), ou le renommer : c'est fort logique, puisqu'il est gestionnaire du classement de la compta…
À retenir, d'une façon générale : les droits (lecture, écriture, exécution) s'appliquent au fichier sur lequel ils sont définis, en tant que données (pour un répertoire, en tant que liste de liens nommés vers des fichiers). Pas au lien, c'est à dire au nom que ce fichier porte dans un ou plusieurs répertoires.
[^] # Re: Zut, j'ai validé... :-)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Sticky bit
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Si j'ai bien compris, tu veux n'autoriser la suppression d'un fichier (en l'occurrence, un répertoire) que pour certaines personnes, qui doivent quand même pouvoir créer et supprimer des fichiers dans le répertoire parent.
Oublions les ACL qui n'ont rien à faire ici : elles ne servent qu'à permettre des attributions plus fines des droits, et non des attributions de droits plus fins. On peut se contenter de parler de droits Unix classiques, tu adapteras selon la granularité à laquelle tu veux les accorder.
Bref, ça se rapproche assez du cas typique d'utilisation du sticky bit, qui, sur un répertoire, permet de n'autoriser la suppression d'un fichier que par le propriétaire de ce fichier. Il est typiquement utilisé dans /tmp, afin que tout le monde puisse y créer des fichiers, mais que personne ne puisse supprimer les fichiers d'autrui :
1777 /tmp
Ou en symbolique, le « t » représentant le sticky bit :
drwxrwxrwt /tmp
[^] # Re: Sticky bit
Posté par Kerro . Évalué à 3.
C'est ton point de vue. Pas le mien :-)
Ce n'est pas celui de Novell (sur leurs ex-système) ni celui de Microsoft.
Je me souviens toujours du système Novell Netware qui permettait même de supprimer l'administrateur des ACLs... Impossible de récupérer les droits avant je ne sais plus quelle version.
[^] # Re: Sticky bit
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Les ACL permettent d'affecter plus finement des droits classiques (lecture, écriture, exécution).
Les attributs étendus permettent d'attribuer des droits plus fins.
[^] # Autre solution
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Parce que, quelque part, si quelqu'un crée un répertoire, mais ne met rien dedans, qu'est-ce que ça peut bien lui faire qu'on lui enlève ? Il n'y a pas de perte de données.
En revanche, s'il y met quelque chose, seuls les gens qui ont le droit d'écrire dans son répertoire (et ça, c'est lui qui le gère) pourront supprimer ce quelque chose, ce qui est un pré-requis pour pouvoir retirer le répertoire (on ne retire pas un répertoire non vide).
# Sticky
Posté par Obsidian . Évalué à 6.
Même chose que tous les autres. Je pense que le sticky bit est ce que tu cherches. Donc, rien à ajouter. Cependant, je peux quand même te traiter de gros nul si ça peut te rendre service. :-)
[^] # Re: Sticky
Posté par Kerro . Évalué à 2.
J'ai vérifier sur un boî-boîte toute faite de chez D-Link, même chose.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.