Depuis mon passage sous Linux (Mandriva pour être précis) je sèche sur un point: le répertoire commun à tous les utilisateurs.
Dernière version essayée: http://linux.jpvweb.com/mesrecetteslinux/commun_utilisateur
Donc avec les acl, tout est tout beau sauf ... avec les applications KDE (entre autre).
Par exemple: les photos éditées avec Digikam (excellent soft au demeurant) et "sauvegardées sous" ne respectent pas les acl ... mais le umask.
Ca m'énerve prodigieusement d'autant que je ne vois pas de solution . Et vous ?
# Partager un ordinateur
Posté par seginus . Évalué à 7.
Ce qui manque (et je pense pourrait être facilement intégrable à un système de fichier), c'est un attribut permettant de supprimer toute permission à un fichier si il est dans un dossier donné.
il existe bien l'attribut g+t me semble-t-il qui permet de mettre à un groupe précis tout les nouveaux fichiers créé dedans.
Mais il faut déjà faire changer l'umask, classiquement mit à 022 (pour une raison que j'ignore) en 002, ce qui parfois pose problème (ce fut le cas il fut un temps sous Ubuntu) à cause de je ne sais quel dossier qui était par défaut créer avec de mauvaises permission, mais le plus gros problème vient du déplacement de fichier dans un tel répertoire, où là, tout les attributs de bases sont préservées (groupe et permission).
Je n'ai à ce jour trouvé aucune solution satisfaisante.
Les ACLs, le permettent peut-être, mais ça demande dans ce cas à être bien mieux implémenté (surtout au niveau des interfaces) pour mettre ça en place.
Et il ne me semble pas avoir de système de fichiers libres (merci de le signaler si il y a) ne gérant pas les permissions (ce qui est quand même plus pratique pour un périphérique amovible. Résultat, pour les clefs et tout, même pour une utilisation 100% Linux, il demeure plus pratique d'utiliser du FAT…
[^] # Re: Partager un ordinateur
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
# ACL roxor !
Posté par eolyte . Évalué à 7.
deux règles à placer, du type :
setfacl -R g:usergroup:rwx
ET
setfacl -R d:g:usergroup:rwx
devraient garantir ta tranquillité.
Si c'est ce que tu avais mis en place, cela signifie que les applis KDE créent les fichiers dans un dossier temporaire, et les déplacent ensuite. Et là, c'est le drame. Plusieurs solutions possibles : placer le dossier temporaire en question sur une autre partition, ou (gruiiiiik) installer un soft de supervision de dossier qui changera les droits quand nécessaire.
[^] # Re: ACL roxor !
Posté par med . Évalué à 9.
[^] # Re: ACL roxor !
Posté par jadfa . Évalué à 2.
[^] # Re: ACL roxor !
Posté par jadfa . Évalué à 1.
Je vous tiens au courant !!
# Groupes?
Posté par wismerhill . Évalué à 4.
Si tu veux simplement un répertoire dont le contenu est accessible à tout le monde la gestion classique des groupes Unix est suffisante.
Tu crée un groupe dans lequel tu met tous tes utilisateurs, tu crée ton répertoire et tu le place dans ce groupe avec les droits d'écriture au groupe et tu positionne le bit SGID du répertoire, ce qui aura pour effet que les fichiers créés dans le répertoire appartiendront aussi au groupe. Enfin, tu positionne pour tous les utilisateurs le umask pour qu'à la création il y aie le droit d'écriture au groupe.
J'ai déjà utilisé ça et ça fonctionne correctement, à condition de ne pas utiliser des programmes qui forcent les permissions à autre chose que les valeurs par défaut (j'ai eu le cas avec des clients (S)FTP) (par contre, s'il y a partage samba en plus c'est un peu plus compliqué)
[^] # Re: Groupes?
Posté par Victor . Évalué à 2.
Ce qui est bien dans les solutions proposées ici (celles avec les ACLs) c'est que c'est un peu comme si on changeait le umask par répertoire.
[^] # Re: Groupes?
Posté par ckyl . Évalué à 4.
Tu crée un groupe dans lequel tu met tous tes utilisateurs, tu crée ton répertoire et tu le place dans ce groupe avec les droits d'écriture au groupe et tu positionne le bit SGID du répertoire, ce qui aura pour effet que les fichiers créés dans le répertoire appartiendront aussi au groupe. Enfin, tu positionne pour tous les utilisateurs le umask pour qu'à la création il y aie le droit d'écriture au groupe.
Aller exceptionnellement je me permets: mais LOL !
Non seulement ta solution n'a vraiment rien de simple mais en plus elle implique la configuration d'une variable globale (umask) pour pouvoir gérer correctement les besoins d'un seul répertoire. Sa solution est beaucoup plus simple (un seul setfacl à faire) et répond parfaitement au besoin.
C'est un problème très connu des droits UNIX, qui se rencontre dès que l'on veut partager des fichiers avec des gens (site web, données d'expérimentations, P2P etc.) et les ACL sont la seule réponse raisonnable. Après le problème est que les GUI gèrent très mal les ACL et qu'en général les montages réseaux ne les supportent pas.
[^] # Re: Groupes?
Posté par Thomas Douillard . Évalué à 2.
Samba doit gérer ça non ? NFS, FTP et consors, sans doute pas effectivement. Les gestionnaires de fichiers Linux pas bien non plus j'ai l'impression ...
Après sous windows de mon expérience c'est pas complètement évident non plus si tu connais pas bien et si tu sais pas exactement ce que tu fais. Par contre je crois que eux ils ont des trucs "simplifiés" pour le novice, genre "autoriser pour tout le monde" dans une case à cocher en cachant la gestion ACL proprement dite.
[^] # Re: Groupes?
Posté par ckyl . Évalué à 2.
La situation n'a pas beaucoup évoluée depuis 2002... C'est la seule solution propre et viable à pas mal de problèmes (non faire tourner des chmod/chgroup en cron root n'est pas une solution). Après les ACL sont complexes à gérer et comprendre car tout les répertoires parents peuvent modifier les permissions obtenues. On peut facilement faire des trucs super compliqués. Mais la majorité des gens veulent faire des trucs super simples qu'il n'est pas possible de faire avec les permissions de base, et avec une GUI correct ça reste humain.
[^] # Re: Groupes?
Posté par ZeroHeure . Évalué à 0.
Avantage: on peut déplacer des fichiers ou dossiers dans le répertoire partagé, les droits d'accès seront ceux du ftp.
A ma connaissance, la solution d'un serveur (ftp, samba, ...) reste la plus simple pour les utilisateurs.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Groupes?
Posté par jadfa . Évalué à 1.
Si je ne trouve pas le répertoire temporaire KDE, je tente le coup en partageant avec Samba (qui tourne déjà pour partager un autre répertoire avec un PC Windows).
[^] # Re: Groupes?
Posté par ZeroHeure . Évalué à -1.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Mais pourquoi ça marche pas ?
Posté par gUI (Mastodon) . Évalué à 3.
Je connaissais pas du tout les ACL, maintenant je me sens moins con (-: Je le serai encore moins le jour où je le mettrai en oeuvre !
Cela dit, je comprends pas pourquoi ça marche pas. Tu dis "les applis KDE le gèrent mal", or si j'ai bien compris c'est au niveau OS (ou plus précisément File SYstem) que ça fonctionne, donc je vois pas en quoi l'appli doit etre "compatible"...
Qqu'un peut expliquer ??? Merci (-:
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mais pourquoi ça marche pas ?
Posté par olivn . Évalué à 1.
# acl et outils
Posté par Dreammm . Évalué à 6.
_ en NFSv3 les acl posix marchent très bien (testé : serveur solaris9 et linux, clients solaris9 et linux)
_ EICIEL est une interface graphique à la gestion d'acl intégrée dans Nautilus (gestionnaire de fichier graphique de gnome)
_ les acl posix et samba, en théorie ça marche, en pratique ...
_ NFSv4 : le système d'ACL est un sur ensemble des acl posix et des acl windows, pas encore super intégré dans les distributions.
_ les utilisateurs ne comprennent pas grand chose aux acl
_ la notion de masque dans les acl est difficile à expliquer (similaire au umask)
La page officielle de Eiciel : http://rofi.roger-ferrer.org/eiciel/
# Ma solution
Posté par Jeanuel (site web personnel) . Évalué à 2.
http://jeanuel.info/spip.php?article67
Ça vaut ce que ça vaut.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.