Naturellement, si tout le monde comprend qu'un cadenas n'est pas
quelque chose de très robuste, on s'attendrai néanmoins de la part
d'une maison d'avoir quelque chose de très sécure sous Linux, en fait
plus une forteresse qu'une maison
Mais voilà
Lorsque on créé un utilisateur, sa "maison" est accessible en lecture
seule par tous les utilisateurs de la machine, et c'est ainsi que le
P4nd4 peut accéder et lire les fichiers de la Gazelle, et les recopier
sur un autre endroit
La maison est donc ouverte toute l'année, et Linux a réussi ici à
inventer la maison sans porte ni fenêtre
Pire encore, le groupe "Autre" possède aussi les accès en lecture, ce
qui est particulièrement dramatique !
Enfin, en bootant sur un CD de Ubuntu, j'ai pu sans problème accéder à
l'ensemble des dossiers de tous les utilisateurs, et y changer tous les
droits d'accès...
Je me serai attendu à mieux de la "maison" Linux...
Et avoir à gérer les droits d'accès à une ressource donnée auprès de X utilisateurs et Y groupes, c'est *DEBILE* !
Gérer utilisateur par utilisateur c'est débile, mais gérer au niveau des groupes, ben c'est le but.
C'est rigolo, on te dit depuis le début qu'avec le bête système rwx, on gère *aussi* les droits d'accès avec des groupes. Qu'il y ait un champ "propriétaire" ne veut pas dire qu'on gère les droits utilisateur par utilisateur...
Pourquoi crois-tu qu'on fait des groupes d'utilisateurs ? Pour pouvoir gérer non pas X utilisateurs, mais 1 seul groupe. Quel est donc l'intérêt d'avoir à gérer Y groupes dans ce cas ?
Alors oui, tu peux trouver des cas de figure complexes ou cela se prête,
Je suis désolé mais encore une fois pas la peine d'aller chercher bien loin : le cas classique où tu veux que certaines personnes (plus d'une) aient un accès en lecture et d'autres (plus d'une) en écriture : impossible avec les ugo+/-rwx, et très simple avec les ACL.
Oui, seulement si le groupe en lecture seule ne s'étend pas à "n'importe qui d'autre". Je suis d'accord, ce n'est pas possible dans ce cas.
Mais il ne faut pas perdre de vue qu'on parle ici d'accès à des dossiers/fichiers. Si on veut gérer des accès à de la documentation, ou que sais-je, le mieux, AMHA, reste d'utiliser une interface type web (sachant que la majorité des entreprises utilise SharePoint, cette idée n'est pas totalement saugrenue). On en revient donc au point de départ : les ACL c'est bien, mais les rwx c'est déjà très très largement suffisant pour une majorité de cas.
Et si vraiment tu as besoin des ACL, tu as les outils pour faire ça sous Linux (ce n'est donc pas impossible en soi).
Après, toutes les solutions sont discutables.
mais ça ne change rien à mon idée de départ : faire des meta-groupes. Un groupe de groupes d'utilisateurs, en somme.
Au moins, dans ce cas, une erreur de manipulation t'amènera généralement à un souci d'accès pour : - 1 utilisateur ciblé, - 1 seul groupe donné, - tout le reste du monde.
Alors qu'avec les ACL : - X utilisateurs - Y groupes - et le reste du monde
Tu peux très bien mettre en oeuvre ton idée avec les ACL, tout en t'imposant la règle d'administration une ressource = un groupe.
Oui, mais tu peux surtout faire comme bon te semble. Il n'y a malheureusement pas d'ACL sur la gestion des ACL :-)
Un système simple, tu ne m'ôteras pas ça de la tête, reste plus robuste et moins sujets à erreurs de manipulation/configuration/administration..
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
"pehache-youplaboum" <pehache.7@gmail.com> a suggéré :
Et avoir à gérer les droits d'accès à une ressource donnée auprès
de X utilisateurs et Y groupes, c'est *DEBILE* !
Gérer utilisateur par utilisateur c'est débile, mais gérer au niveau
des groupes, ben c'est le but.
C'est rigolo, on te dit depuis le début qu'avec le bête système rwx, on
gère *aussi* les droits d'accès avec des groupes.
Qu'il y ait un champ "propriétaire" ne veut pas dire qu'on gère les
droits utilisateur par utilisateur...
Pourquoi crois-tu qu'on fait des groupes d'utilisateurs ? Pour
pouvoir gérer non pas X utilisateurs, mais 1 seul groupe. Quel
est donc l'intérêt d'avoir à gérer Y groupes dans ce cas ?
Alors oui, tu peux trouver des cas de figure complexes ou cela se
prête,
Je suis désolé mais encore une fois pas la peine d'aller chercher bien
loin : le cas classique où tu veux que certaines personnes (plus
d'une) aient un accès en lecture et d'autres (plus d'une) en écriture
: impossible avec les ugo+/-rwx, et très simple avec les ACL.
Oui, seulement si le groupe en lecture seule ne s'étend pas à "n'importe
qui d'autre". Je suis d'accord, ce n'est pas possible dans ce cas.
Mais il ne faut pas perdre de vue qu'on parle ici d'accès à des
dossiers/fichiers. Si on veut gérer des accès à de la documentation, ou
que sais-je, le mieux, AMHA, reste d'utiliser une interface type web
(sachant que la majorité des entreprises utilise SharePoint, cette idée
n'est pas totalement saugrenue).
On en revient donc au point de départ : les ACL c'est bien, mais les rwx
c'est déjà très très largement suffisant pour une majorité de cas.
Et si vraiment tu as besoin des ACL, tu as les outils pour faire ça sous
Linux (ce n'est donc pas impossible en soi).
Après, toutes les solutions sont discutables.
mais ça ne change rien à mon idée de départ : faire des
meta-groupes. Un groupe de groupes d'utilisateurs, en somme.
Au moins, dans ce cas, une erreur de manipulation t'amènera
généralement à un souci d'accès pour :
- 1 utilisateur ciblé,
- 1 seul groupe donné,
- tout le reste du monde.
Alors qu'avec les ACL :
- X utilisateurs
- Y groupes
- et le reste du monde
Tu peux très bien mettre en oeuvre ton idée avec les ACL, tout en
t'imposant la règle d'administration une ressource = un groupe.
Oui, mais tu peux surtout faire comme bon te semble. Il n'y a
malheureusement pas d'ACL sur la gestion des ACL :-)
Un système simple, tu ne m'ôteras pas ça de la tête, reste plus robuste
et moins sujets à erreurs de manipulation/configuration/administration..
Et avoir à gérer les droits d'accès à une ressource donnée auprès de X utilisateurs et Y groupes, c'est *DEBILE* !
Gérer utilisateur par utilisateur c'est débile, mais gérer au niveau des groupes, ben c'est le but.
C'est rigolo, on te dit depuis le début qu'avec le bête système rwx, on gère *aussi* les droits d'accès avec des groupes. Qu'il y ait un champ "propriétaire" ne veut pas dire qu'on gère les droits utilisateur par utilisateur...
Pourquoi crois-tu qu'on fait des groupes d'utilisateurs ? Pour pouvoir gérer non pas X utilisateurs, mais 1 seul groupe. Quel est donc l'intérêt d'avoir à gérer Y groupes dans ce cas ?
Alors oui, tu peux trouver des cas de figure complexes ou cela se prête,
Je suis désolé mais encore une fois pas la peine d'aller chercher bien loin : le cas classique où tu veux que certaines personnes (plus d'une) aient un accès en lecture et d'autres (plus d'une) en écriture : impossible avec les ugo+/-rwx, et très simple avec les ACL.
Oui, seulement si le groupe en lecture seule ne s'étend pas à "n'importe qui d'autre". Je suis d'accord, ce n'est pas possible dans ce cas.
Mais il ne faut pas perdre de vue qu'on parle ici d'accès à des dossiers/fichiers. Si on veut gérer des accès à de la documentation, ou que sais-je, le mieux, AMHA, reste d'utiliser une interface type web (sachant que la majorité des entreprises utilise SharePoint, cette idée n'est pas totalement saugrenue). On en revient donc au point de départ : les ACL c'est bien, mais les rwx c'est déjà très très largement suffisant pour une majorité de cas.
Et si vraiment tu as besoin des ACL, tu as les outils pour faire ça sous Linux (ce n'est donc pas impossible en soi).
Après, toutes les solutions sont discutables.
mais ça ne change rien à mon idée de départ : faire des meta-groupes. Un groupe de groupes d'utilisateurs, en somme.
Au moins, dans ce cas, une erreur de manipulation t'amènera généralement à un souci d'accès pour : - 1 utilisateur ciblé, - 1 seul groupe donné, - tout le reste du monde.
Alors qu'avec les ACL : - X utilisateurs - Y groupes - et le reste du monde
Tu peux très bien mettre en oeuvre ton idée avec les ACL, tout en t'imposant la règle d'administration une ressource = un groupe.
Oui, mais tu peux surtout faire comme bon te semble. Il n'y a malheureusement pas d'ACL sur la gestion des ACL :-)
Un système simple, tu ne m'ôteras pas ça de la tête, reste plus robuste et moins sujets à erreurs de manipulation/configuration/administration..
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Michel__D
Bonjour,
Stephan Peccini a écrit :
À comparer, il faut le faire entre Nautilus et l'interface de Windows. Il est possible de demander à Nautilus de passer en lecture seule un fichier sur un système de fichiers non sensible à la commande mais immédiatement après il repositionne correctement les attributs du fichiers. Ce qui revient à faire chmod -w toto puis ls -l toto, ce qui est normal. Si sous Windows (ce que je n'ai pas vérifié), passer un fichier en lecture seule alors que le système de fichiers ne le permet pas et ne pas vérifier que l'action a bien été menée en laissant la case cochée en lecture seule, est par contre une erreur car une interface graphique doit rendre toutes les actions transparentes et redonner l'état final réel après l'action.
Puisque personne ne si colle j'ai fait le test dans une machine virtuelle cela tombe bien j'ai (en virtuel) un multiboot avec Seven (NTFS), XP (FAT32) et Ubuntu 10.04 (EXT4) l'hote étant Vista (pour le réseaux) avec UAC inactif.
Bien le décors étant planté, voici les résultats :
1) Avec Seven en action, l'interface de Windows (explorer.exe) prend bien en compte l'attribut "Lecture seule" sur un fichier aussi bien en FAT32 que NTFS ce qui se traduit par l'ouverture d'une fenêtre "Enregistrer sous" lorsque l'on cherche à enregistrer un fichier modifié en lecture seule autant en local qu'en réseau.
De plus l'état de l'attribut "Lecture seule" est bien retransmis que cette opération soit réalisé en local ou soit en réseau du client ou du serveur (machine distante).
Donc RAS avec windows.
2) Avec Ubuntu 10.04 et Nautilus en action (en local) :
-Sur un volume FAT32, l'attribut "Lecture seule" est bien pris en compte avec possibilité "d'enregistrer sous" lorsque'un fichier en lecture seule est modifié.
L'état de l'attribut "Lecture seule" est bien retransmis.
-Sur un volume NTFS, l'attribut "Lecture seule" n'est pas pris en compte toute tentative de changement revient toujours à "Lecture et écriture".
Donc on peut en conclure qu'avec un volume NTFS, les fichiers sont accessibles à tout le monde à partir d'Ubuntu 10.04.
C'est ce que semble dire le commentaire situé tout en bas du lien ci-dessous.
http://doc.ubuntu-fr.org/systeme_de_fichiers
3) Avec Ubuntu 10.04 et Nautilus en action (ressource réseau partagé) :
Je précise donc que les ressources partagés sont sous Vista avec pour simplifier "Contrôle total" pour "Tout le monde" au niveau des droits du partage aussi bien sur une ressource partagé (FAT32) que sur une ressource partagé (NTFS) et l'utilisateur possède les droits NTFS de lecture/écriture.
Et bien j'accéde bien aux différentes ressources partagés sans aucune difficulté en lecture/écriture ce qui est correct par rapport au paramêtrage des droits de partage, mais car il y a un mais je n'ai aucune possibilité d'agir au niveau des permissions car elles sont inconnus/impossible à déterminer.
Nota: Le comportement avec les fichiers modifiés ayant l'attribut "Lecture seule" au niveau des ressources partagés est identique au comportement en local (possibilité d'enregistrer sous).
Voila pour la comparaison.
Bonjour,
Stephan Peccini a écrit :
À comparer, il faut le faire entre Nautilus et l'interface de Windows.
Il est possible de demander à Nautilus de passer en lecture seule un
fichier sur un système de fichiers non sensible à la commande mais
immédiatement après il repositionne correctement les attributs du
fichiers. Ce qui revient à faire chmod -w toto puis ls -l toto, ce qui
est normal.
Si sous Windows (ce que je n'ai pas vérifié), passer un fichier en
lecture seule alors que le système de fichiers ne le permet pas et ne
pas vérifier que l'action a bien été menée en laissant la case cochée en
lecture seule, est par contre une erreur car une interface graphique
doit rendre toutes les actions transparentes et redonner l'état final
réel après l'action.
Puisque personne ne si colle j'ai fait le test dans une machine virtuelle
cela tombe bien j'ai (en virtuel) un multiboot avec Seven (NTFS), XP (FAT32)
et Ubuntu 10.04 (EXT4) l'hote étant Vista (pour le réseaux) avec UAC inactif.
Bien le décors étant planté, voici les résultats :
1) Avec Seven en action, l'interface de Windows (explorer.exe) prend bien en
compte l'attribut "Lecture seule" sur un fichier aussi bien en FAT32 que NTFS
ce qui se traduit par l'ouverture d'une fenêtre "Enregistrer sous" lorsque
l'on cherche à enregistrer un fichier modifié en lecture seule autant en local
qu'en réseau.
De plus l'état de l'attribut "Lecture seule" est bien retransmis que cette opération
soit réalisé en local ou soit en réseau du client ou du serveur (machine distante).
Donc RAS avec windows.
2) Avec Ubuntu 10.04 et Nautilus en action (en local) :
-Sur un volume FAT32, l'attribut "Lecture seule" est bien pris en compte avec
possibilité "d'enregistrer sous" lorsque'un fichier en lecture seule est modifié.
L'état de l'attribut "Lecture seule" est bien retransmis.
-Sur un volume NTFS, l'attribut "Lecture seule" n'est pas pris en compte toute
tentative de changement revient toujours à "Lecture et écriture".
Donc on peut en conclure qu'avec un volume NTFS, les fichiers sont accessibles
à tout le monde à partir d'Ubuntu 10.04.
C'est ce que semble dire le commentaire situé tout en bas du lien ci-dessous.
http://doc.ubuntu-fr.org/systeme_de_fichiers
3) Avec Ubuntu 10.04 et Nautilus en action (ressource réseau partagé) :
Je précise donc que les ressources partagés sont sous Vista avec pour simplifier
"Contrôle total" pour "Tout le monde" au niveau des droits du partage aussi bien
sur une ressource partagé (FAT32) que sur une ressource partagé (NTFS) et
l'utilisateur possède les droits NTFS de lecture/écriture.
Et bien j'accéde bien aux différentes ressources partagés sans aucune difficulté
en lecture/écriture ce qui est correct par rapport au paramêtrage des droits de
partage, mais car il y a un mais je n'ai aucune possibilité d'agir au niveau des
permissions car elles sont inconnus/impossible à déterminer.
Nota: Le comportement avec les fichiers modifiés ayant l'attribut "Lecture seule"
au niveau des ressources partagés est identique au comportement en local
(possibilité d'enregistrer sous).
À comparer, il faut le faire entre Nautilus et l'interface de Windows. Il est possible de demander à Nautilus de passer en lecture seule un fichier sur un système de fichiers non sensible à la commande mais immédiatement après il repositionne correctement les attributs du fichiers. Ce qui revient à faire chmod -w toto puis ls -l toto, ce qui est normal. Si sous Windows (ce que je n'ai pas vérifié), passer un fichier en lecture seule alors que le système de fichiers ne le permet pas et ne pas vérifier que l'action a bien été menée en laissant la case cochée en lecture seule, est par contre une erreur car une interface graphique doit rendre toutes les actions transparentes et redonner l'état final réel après l'action.
Puisque personne ne si colle j'ai fait le test dans une machine virtuelle cela tombe bien j'ai (en virtuel) un multiboot avec Seven (NTFS), XP (FAT32) et Ubuntu 10.04 (EXT4) l'hote étant Vista (pour le réseaux) avec UAC inactif.
Bien le décors étant planté, voici les résultats :
1) Avec Seven en action, l'interface de Windows (explorer.exe) prend bien en compte l'attribut "Lecture seule" sur un fichier aussi bien en FAT32 que NTFS ce qui se traduit par l'ouverture d'une fenêtre "Enregistrer sous" lorsque l'on cherche à enregistrer un fichier modifié en lecture seule autant en local qu'en réseau.
De plus l'état de l'attribut "Lecture seule" est bien retransmis que cette opération soit réalisé en local ou soit en réseau du client ou du serveur (machine distante).
Donc RAS avec windows.
2) Avec Ubuntu 10.04 et Nautilus en action (en local) :
-Sur un volume FAT32, l'attribut "Lecture seule" est bien pris en compte avec possibilité "d'enregistrer sous" lorsque'un fichier en lecture seule est modifié.
L'état de l'attribut "Lecture seule" est bien retransmis.
-Sur un volume NTFS, l'attribut "Lecture seule" n'est pas pris en compte toute tentative de changement revient toujours à "Lecture et écriture".
Donc on peut en conclure qu'avec un volume NTFS, les fichiers sont accessibles à tout le monde à partir d'Ubuntu 10.04.
C'est ce que semble dire le commentaire situé tout en bas du lien ci-dessous.
http://doc.ubuntu-fr.org/systeme_de_fichiers
3) Avec Ubuntu 10.04 et Nautilus en action (ressource réseau partagé) :
Je précise donc que les ressources partagés sont sous Vista avec pour simplifier "Contrôle total" pour "Tout le monde" au niveau des droits du partage aussi bien sur une ressource partagé (FAT32) que sur une ressource partagé (NTFS) et l'utilisateur possède les droits NTFS de lecture/écriture.
Et bien j'accéde bien aux différentes ressources partagés sans aucune difficulté en lecture/écriture ce qui est correct par rapport au paramêtrage des droits de partage, mais car il y a un mais je n'ai aucune possibilité d'agir au niveau des permissions car elles sont inconnus/impossible à déterminer.
Nota: Le comportement avec les fichiers modifiés ayant l'attribut "Lecture seule" au niveau des ressources partagés est identique au comportement en local (possibilité d'enregistrer sous).
Voila pour la comparaison.
pehache-youplaboum
"Stephan Peccini" a écrit dans le message de news: i9m8kg$1j4$
Et que dire de Linux qui laisse faire sans aucun message d'erreur ou warning, un chmod -w qui n'a aucun effet ?
Le chmod ne remonte une erreur que si le système de fichiers en remonte une ; si le système de fichiers n'est pas sensible au chmod et ne remonte pas d'erreur, ce n'est pas le problème du chmod.
Et tu trouves normal que le driver du système de fichier ne remonte aucune erreur ??
-- pehache http://pehache.free.fr
"Stephan Peccini" <stephan@photonature.fr> a écrit dans le message de
news: i9m8kg$1j4$1@eweb.domicile
Et que dire de Linux qui laisse faire sans aucun message d'erreur ou
warning, un chmod -w qui n'a aucun effet ?
Le chmod ne remonte une erreur que si le système de fichiers en
remonte une ; si le système de fichiers n'est pas sensible au chmod
et ne remonte pas d'erreur, ce n'est pas le problème du chmod.
Et tu trouves normal que le driver du système de fichier ne remonte aucune
erreur ??
"Stephan Peccini" a écrit dans le message de news: i9m8kg$1j4$
Et que dire de Linux qui laisse faire sans aucun message d'erreur ou warning, un chmod -w qui n'a aucun effet ?
Le chmod ne remonte une erreur que si le système de fichiers en remonte une ; si le système de fichiers n'est pas sensible au chmod et ne remonte pas d'erreur, ce n'est pas le problème du chmod.
Et tu trouves normal que le driver du système de fichier ne remonte aucune erreur ??
