🚲 Tanguy Ortolo a écrit 12091 commentaires

Autre façon de voir les choses  : pense en terme de niveaux de répertoires et de délégation de pouvoir. Si dans la compte, une équipe (appelons-la planning), composée de Titi et de Toto, a besoin de stocker des données, elle va avoir besoin d'un répertoire et du droit d'écrire dedans. Ce droit va lui être attribué par une chaîne de délégation de droits, matérialisée par un chemin de répertoires : root a créé le partage réseau, des gens peuvent créer des répertoires dedans, en autorisent d'autre à créer des sous-répertoires, etc. L'existence et le nom de ce répertoire sont du ressort du niveau supérieur : cette équipe a son répertoire, et fait ce qu'elle veut dedans.

Il y a une contradiction dans ton cas.

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.

Les ACL ne permettent pas d'attribuer des droits plus fins.

Les ACL permettent d'affecter plus finement des droits classiques (lecture, écriture, exécution).

Les attributs étendus permettent d'attribuer des droits plus fins.

N'importe quoi.

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

Autre solution : fais en sorte que tout le monde puisse écrire dans ton répertoire, mais s'ils veulent empêcher que quelqu'un d'autre enlève les répertoires qu'ils ont créés, qu'ils mettent des fichiers dedans.

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).

La « suppression » et la « création » de fichiers ne sont pas des droits. Les droits correspondants sont l'écriture dans le répertoire parent.

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

Et très nul pour faire des recherches ailleurs que sur un seul moteur de recherche par défaut.

Non, pas le bon bout. Au lieu de commencer par utiliser le standard IETF que les grands noms n'utilisent pas encore et n'utiliseront sans doute jamais – sauf peut-être des boîtes dynamiques comme Google –, ils commencent par leur standard maison que personne n'utilise encore non plus.

Certes, la méthode Mozilla est plus puissante, mais sa souplesse est assez peu utile. La méthode IETF, c'est :
— chercher les enregistrements pop3 et imap ;
— laisser le choix entre POP3 et IMAP si les deux sont disponibles ;
— demander un mot de passe ;
— essayer de s'identifier avec comme login l'adresse complète, puis la partie locale.

Je ne critique pas la mode kludgesque actuel, mais l'absence d'implémentation du standard efficace. La façon normal de procéder, ç'aurait été d'utiliser le standard pour les types modernes qui l'implémentent, et de passer en mode crade qui marche (lentement, au passage) pour les autres.

D'accord. :-)

Sauf qu'on ne peut pas faire dans Thunderbird tout ce qu'on peut faire dans Mutt, très loin de là. Et, réciproquement, quelques fonctions de Thunderbird ne se retrouvent pas dans Mutt.

Au passage, pour faire à la fois de l'IMAP et du déconnecté, je te conseille OfflineIMAP. Ça permet de faire un synchronisation totale entre un IMAP et un Maildir, puis d'utiliser Mutt sur ce Maildir. Et c'est en outre le client IMAP le plus rapide que j'ai jamais vu.

J'en reçois régulièrement, pourquoi ? Je les ouvre, et d'après mon mailcap, ça utilise pour cela Eye of GNOME.

Je reçois même des messages en pur HTML, que je lis comme s'ils étaient en texte pur après conversion par lynx. Je reçois aussi des messages avec des fichiers attachés en PDF, en OpenDocument Text ou en Word, que je lis à la suite des messages, en texte, après conversion par pdftotext, odt2txt ou antiword.

Je peux même ouvrir ces HTML, PDF, OpenDocument ou Word avec un logiciel graphique, puisqu'ils sont placés avant leurs équivalents textes dans mon mailcap.

C'est que tu n'as pas encore configuré et commencé à utiliser Mutt. Ça viendra.

Zsh saymieux.

tu es vraiment resté à l'époque de l'Internet à pépé ou quoi ?

Et toi, ça fait combien de temps que tu as utilisé Thunderbird, pépé ?

Quand tu n'as pas de connexion Internet, GMail ou pas, tu es déjà à la préhistoire de l'informatique

Désolé, mais ce n'est pas parce que toi, tu es on ze cloud, perdu sans ta connexion, que tout le monde est dans le même cas. Personnellement, sans connexion, évidemment je ne peux pas communiquer, mais mes données sont toujours chez moi.

tu es vraiment resté à l'époque de l'Internet à pépé ou quoi ?

les utilisateurs obsolètes de Thunderbird

Bon. Moinssons ces propos irrespectueux.

Il faut quand même avouer que gérer ses mails via Thunderbird c'est tout de même un autre monde : quand tu utilises GMail, tu as l'impression d'être à la préhistoire de l'informatique tellement c'est indisponible quand tu n'as pas de connexion à Internet et que c'est peu efficace comparé à Thunderbird, beaucoup plus disponible et pratique, surtout pour lire son courrier dans le train.

Il faut quand même avouer que gérer son courrier via GMail, c'est tout de même un autre monde : Ils ne sont pas chez toi, ne passent pas par chez toi, et sont hors de ton contrôle.

Si seule l'efficacité t'intéresse, reste chez Google. Vends-toi à Google, c'est ton choix, tant mieux si tu es heureux. Tu ne contrôles plus rien, tu dépends complètement d'un prestataire qui peut faire ce qu'il veut, mais si tu l'as choisis librement et que tu en es content, tant mieux pour toi. J'en ai assez de ces « c'est mieux chez Google ». Évidemment que c'est mieux par certains points, et moins bien par d'autres, si vous préférez, restez-y, pas la peine de la ramener.

D'autres considèrent qu'il est important de contrôler ses données personnelles, et sont prêts à supporter pour cela les inconvénients évidents que cela peut avoir.

Je considère personnellement que ma liberté est infiniment plus précieuse que le temps de recherche dans mon courrier, d'autant plus que je n'ai pas besoin de faire de recherches compliquées puisque je le classe. Je sais que je n'ai pas la puissance de calcul de Google, et je me contente de ce que j'ai, fier d'être libre et dépendant uniquement de moi-même et de mon FAI.

Les serveurs courants n'en ont rien à faire, et pour ça une base de données est plutôt une bonne idée, pour pallier à leurs déficiences ou leur manque de dynamisme.

Mais les serveurs tenus par des gens dynamiques, eux, mériteraient qu'on tire profit de leur compétence.

C'est bien beau (ou pas), une description en texte brut. Mais :
— en wrappant le texte, c'est mieux ;
— depuis, on a inventé HTML.

Notez que cette « découverte » est :
— kludgesque : utiliser une base de données pour des noms de domaine privilégiés qui ne publient pas les informations SRV qui vont bien ;
— complètement artisanale : si ce n'est pas dans la base, on essaie tout (pop.[nom], imap.[nom], smtp.[nom], [nom] tout court) sur tous les ports (pop3, imap, pop3s, imaps, smtp, smtps, submission) ;
— non standard : depuis, on a inventé les enregistrements SRV pour obtenir les informations sans bidouillage, mais Thunderbird ne s'en sert pas.

Bon, templeet a mangé mes chevrons, donc je recommence.

Il cherche dans la base, puis cherche pop.[nom], puis imap.[nom] pour trouver le serveur de boîtes aux lettres, et smtp.[nom] pour trouver le serveur relais.

Le serveur de courrier (enregistrement MX, souvent associé à un nom du style mail.[nom]), il n'en a pas besoin, ce n'est pas son travail. Thunderbird n'est pas un serveur relais.

Cessez de confondre serveur de courrier, serveur relais et serveur de boîtes aux lettres…

Il cherche dans la base, puis cherche pop., puis imap. pour trouver le serveur de boîtes aux lettres, et smtp. pour trouver le serveur relais.

Le serveur de courrier (enregistrement MX, souvent associé à un nom du style mail.), il n'en a pas besoin, ce n'est pas son travail. Thunderbird n'est pas un serveur relais.

Cessez de confondre serveur de courrier, serveur relais et serveur de boîtes aux lettres…

Thunderbird implémente-t-il maintenant l'auto-découverte standard à coup d'enregistrements DNS SRV ?

… sans JavaScript. C'est dommage – et probablement très peu accessible.