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...
Le 13/10/10 01:47, Yliur a écrit : [Accès en lecture seule]
Rien à voir avec le noyau Linux, c'est un choix des distributions. Mais je ne comprends pas ce choix non plus. Une vieille tradition Unix sans doute, mais bon ça craint quand même...
C'est indispensable si p.ex. on veut que les utilisateurs puissent mettre en ligne des pages web en les déposant dans /home/user/public_html, celles-ci étant accessible via http://machine/~user/
Non, ton ~ doit avoir des droits en exécution, mais pas besoin d'avoir les droits en lecture. (+x pour un dossier autorise à le traverser. -r interdit de lister son contenu, donc de voir quels sont les fichiers/dossiers présents...)
Pour un site web, tu feras donc un go+x,go-rw ~, et un go+rx,go-w sur ton ~/www (ou ~/public_html , plus souvent) pour le rendre accessible, sans pour autant donner accès à tout le contenu de ton ~.
En clair, si tu veux "couper" l'accès à un dossier donné, il te suffit d'enlever le droit "x" à la partie qui va bien, à n'importe quel dossier parent dans le chemin (impossible d'accéder au dossier donné, ni à ses sous-dossiers).
L'avantage de cette solution est qu'il n'y a pas 36 façons d'accéder à un dossier, donc on peut vérifier rapidement et clairement les droits avec un simple "namei -m $PWD".
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Jerome Lambert <jerome.lambert@swing.be> a suggéré :
Le 13/10/10 01:47, Yliur a écrit :
[Accès en lecture seule]
Rien à voir avec le noyau Linux, c'est un choix des distributions. Mais
je ne comprends pas ce choix non plus. Une vieille tradition Unix sans
doute, mais bon ça craint quand même...
C'est indispensable si p.ex. on veut que les utilisateurs puissent
mettre en ligne des pages web en les déposant dans
/home/user/public_html, celles-ci étant accessible via
http://machine/~user/
Non, ton ~ doit avoir des droits en exécution, mais pas besoin d'avoir
les droits en lecture.
(+x pour un dossier autorise à le traverser. -r interdit de lister son
contenu, donc de voir quels sont les fichiers/dossiers présents...)
Pour un site web, tu feras donc un go+x,go-rw ~, et un go+rx,go-w sur
ton ~/www (ou ~/public_html , plus souvent) pour le rendre accessible,
sans pour autant donner accès à tout le contenu de ton ~.
En clair, si tu veux "couper" l'accès à un dossier donné, il te suffit
d'enlever le droit "x" à la partie qui va bien, à n'importe quel dossier
parent dans le chemin (impossible d'accéder au dossier donné, ni à ses
sous-dossiers).
L'avantage de cette solution est qu'il n'y a pas 36 façons d'accéder à
un dossier, donc on peut vérifier rapidement et clairement les droits
avec un simple "namei -m $PWD".
Le 13/10/10 01:47, Yliur a écrit : [Accès en lecture seule]
Rien à voir avec le noyau Linux, c'est un choix des distributions. Mais je ne comprends pas ce choix non plus. Une vieille tradition Unix sans doute, mais bon ça craint quand même...
C'est indispensable si p.ex. on veut que les utilisateurs puissent mettre en ligne des pages web en les déposant dans /home/user/public_html, celles-ci étant accessible via http://machine/~user/
Non, ton ~ doit avoir des droits en exécution, mais pas besoin d'avoir les droits en lecture. (+x pour un dossier autorise à le traverser. -r interdit de lister son contenu, donc de voir quels sont les fichiers/dossiers présents...)
Pour un site web, tu feras donc un go+x,go-rw ~, et un go+rx,go-w sur ton ~/www (ou ~/public_html , plus souvent) pour le rendre accessible, sans pour autant donner accès à tout le contenu de ton ~.
En clair, si tu veux "couper" l'accès à un dossier donné, il te suffit d'enlever le droit "x" à la partie qui va bien, à n'importe quel dossier parent dans le chemin (impossible d'accéder au dossier donné, ni à ses sous-dossiers).
L'avantage de cette solution est qu'il n'y a pas 36 façons d'accéder à un dossier, donc on peut vérifier rapidement et clairement les droits avec un simple "namei -m $PWD".
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
(Michel Talon) a suggéré :
Pratiquement tous les systèmes Unix auxquels j'ai eu accés ont cette configuration par défaut, parceque c'est la meilleure pour la plupart des gens, sauf pour les dingos de la cachotterie qui se mettent un umask et changent leurs permissions. Un système de permissions plus restrictif a un seul résultat, emmerder tout le monde au point que tout le monde devient administrateur. Et c'est *totalement* inutile face à un hacker compétent qui arrivera toujours à devenir super utilisateur d'une manière ou d'une autre.
Excellente synthèse.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
talon@lpthe.jussieu.fr (Michel Talon) a suggéré :
Pratiquement tous les systèmes Unix auxquels j'ai eu accés ont cette
configuration par défaut, parceque c'est la meilleure pour la plupart des
gens, sauf pour les dingos de la cachotterie qui se mettent un umask
et changent leurs permissions. Un système de permissions plus restrictif
a un seul résultat, emmerder tout le monde au point que tout le monde
devient administrateur. Et c'est *totalement* inutile face à un hacker
compétent qui arrivera toujours à devenir super utilisateur d'une
manière ou d'une autre.
Pratiquement tous les systèmes Unix auxquels j'ai eu accés ont cette configuration par défaut, parceque c'est la meilleure pour la plupart des gens, sauf pour les dingos de la cachotterie qui se mettent un umask et changent leurs permissions. Un système de permissions plus restrictif a un seul résultat, emmerder tout le monde au point que tout le monde devient administrateur. Et c'est *totalement* inutile face à un hacker compétent qui arrivera toujours à devenir super utilisateur d'une manière ou d'une autre.
Excellente synthèse.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Nicolas George
Hugues , dans le message , a écrit :
Non, ton ~ doit avoir des droits en exécution, mais pas besoin d'avoir les droits en lecture.
Et encore, j'avais oublié de le mentionner dans mon message précédent : ça peut n'être que pour le groupe www-data, pas forcément pour tous.
Hugues , dans le message <8739s9gdxj.fsf@paranoid.sweethome>, a écrit :
Non, ton ~ doit avoir des droits en exécution, mais pas besoin d'avoir
les droits en lecture.
Et encore, j'avais oublié de le mentionner dans mon message précédent : ça
peut n'être que pour le groupe www-data, pas forcément pour tous.
Non, ton ~ doit avoir des droits en exécution, mais pas besoin d'avoir les droits en lecture.
Et encore, j'avais oublié de le mentionner dans mon message précédent : ça peut n'être que pour le groupe www-data, pas forcément pour tous.
totof01
On 14 oct, 00:46, ST wrote:
On 10/13/10 10:30 PM, totof01 wrote:
> As-tu déjà eu affaire sérieusement au système de droits sous wi ndows ? > Moi oui, donc je sais de quoi je parle. Après que les virus ou autres > joyeusetés utilisent les failles de windows pour outrepasser ces > droits, ou que l'administrateur ne soit pas capable de les gérer > correctement, c'est un autre problème. Mais avec Windows tu peux fair e > bien plus que RWX sur un fichier/répertoire. Et pour avoir un > comportement similaire avec Unix, il faut jouer avec les ACL.
Je n'ai jamais eu un cas en 15 ans de métier ou RWX ne m'a pas suffit à résoudre un problème de droit sur les fichiers.
Je ne sais même pas me servir des ACLs sous Linux parce que je n'ai jamais eu ce besoin. RWX répond a 99% des besoins, c'est simple et ça fonctionne. Windows offre plus, mais c'est un plus complexe et inutile.
Le mieux est parfois l'ennemi du bien.
Il m'est arrivé personnellement de devoir les utiliser dans certains cas précis. C'est la fonctionnalité qui ne manque pas dans 99% des cas, mais orsque tu te trouves dans le 1% qui reste t'es bien content de les avoir.
On 14 oct, 00:46, ST <s...@unices.org> wrote:
On 10/13/10 10:30 PM, totof01 wrote:
> As-tu déjà eu affaire sérieusement au système de droits sous wi ndows ?
> Moi oui, donc je sais de quoi je parle. Après que les virus ou autres
> joyeusetés utilisent les failles de windows pour outrepasser ces
> droits, ou que l'administrateur ne soit pas capable de les gérer
> correctement, c'est un autre problème. Mais avec Windows tu peux fair e
> bien plus que RWX sur un fichier/répertoire. Et pour avoir un
> comportement similaire avec Unix, il faut jouer avec les ACL.
Je n'ai jamais eu un cas en 15 ans de métier ou RWX ne m'a pas suffit à
résoudre un problème de droit sur les fichiers.
Je ne sais même pas me servir des ACLs sous Linux parce que je n'ai
jamais eu ce besoin. RWX répond a 99% des besoins, c'est simple et ça
fonctionne. Windows offre plus, mais c'est un plus complexe et inutile.
Le mieux est parfois l'ennemi du bien.
Il m'est arrivé personnellement de devoir les utiliser dans certains
cas précis. C'est la fonctionnalité qui ne manque pas dans 99% des
cas, mais orsque tu te trouves dans le 1% qui reste t'es bien content
de les avoir.
> As-tu déjà eu affaire sérieusement au système de droits sous wi ndows ? > Moi oui, donc je sais de quoi je parle. Après que les virus ou autres > joyeusetés utilisent les failles de windows pour outrepasser ces > droits, ou que l'administrateur ne soit pas capable de les gérer > correctement, c'est un autre problème. Mais avec Windows tu peux fair e > bien plus que RWX sur un fichier/répertoire. Et pour avoir un > comportement similaire avec Unix, il faut jouer avec les ACL.
Je n'ai jamais eu un cas en 15 ans de métier ou RWX ne m'a pas suffit à résoudre un problème de droit sur les fichiers.
Je ne sais même pas me servir des ACLs sous Linux parce que je n'ai jamais eu ce besoin. RWX répond a 99% des besoins, c'est simple et ça fonctionne. Windows offre plus, mais c'est un plus complexe et inutile.
Le mieux est parfois l'ennemi du bien.
Il m'est arrivé personnellement de devoir les utiliser dans certains cas précis. C'est la fonctionnalité qui ne manque pas dans 99% des cas, mais orsque tu te trouves dans le 1% qui reste t'es bien content de les avoir.
Hugolino
Le 14-10-2010, Hugues a écrit :
[...] Le truc, c'est qu'avec Unix c'est facile.
Sous windows, je n'ai jamais réussi à trouver un moyen de gérer les droits proprement, simplement, et sans que ça fasse chier tout le monde... C'était peut être facile, peut être pas, en tout cas ça n'a pas été clair pour moi dès le début.. [...]
+1
On a longtemps expliqué le succès de windows® par sa vivialité : tout y serait « Mme Michu compliant ». Mais dès qu'on tombe (rapidement) sur des petits problèmes qui seraient faciles à régler avec un unixoïde, on sombre très rapidement dans le shadokisme le plus abscons.
Et il n'existe pas de doc, ou alors en suivant un stage "Most Value Pigeon" à watt-mille brouzoufs pour bien te faire sentir, par la douloureuse, que tu es maintenant admis dans le saint des saints de la connaissance ultime du système : du marketing pour analphabètes de l'1-faux et autres techno-crétins.
Avec un unixoïde comme linux, on simplifie les choses au maximum de manière qu'il est évident qu'il n'y a pas de défaut. Avec windows®, on complexifie les choses le plus possible tel qu'il est impossible de trouver les défauts qui sinon seraient évidents.
[x-post et fu2 fourbe]
--
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car un clavier AZERTY en vaut 2.
Le 14-10-2010, Hugues <hugues@hiegel.fr> a écrit :
[...]
Le truc, c'est qu'avec Unix c'est facile.
Sous windows, je n'ai jamais réussi à trouver un moyen de gérer les
droits proprement, simplement, et sans que ça fasse chier tout le
monde... C'était peut être facile, peut être pas, en tout cas ça n'a pas
été clair pour moi dès le début.. [...]
+1
On a longtemps expliqué le succès de windows® par sa vivialité : tout
y serait « Mme Michu compliant ».
Mais dès qu'on tombe (rapidement) sur des petits problèmes qui seraient
faciles à régler avec un unixoïde, on sombre très rapidement dans le
shadokisme le plus abscons.
Et il n'existe pas de doc, ou alors en suivant un stage "Most Value
Pigeon" à watt-mille brouzoufs pour bien te faire sentir, par la
douloureuse, que tu es maintenant admis dans le saint des saints de la
connaissance ultime du système : du marketing pour analphabètes de
l'1-faux et autres techno-crétins.
Avec un unixoïde comme linux, on simplifie les choses au maximum de
manière qu'il est évident qu'il n'y a pas de défaut.
Avec windows®, on complexifie les choses le plus possible tel qu'il est
impossible de trouver les défauts qui sinon seraient évidents.
[x-post et fu2 fourbe]
--
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je
voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car
un clavier AZERTY en vaut 2.
Sous windows, je n'ai jamais réussi à trouver un moyen de gérer les droits proprement, simplement, et sans que ça fasse chier tout le monde... C'était peut être facile, peut être pas, en tout cas ça n'a pas été clair pour moi dès le début.. [...]
+1
On a longtemps expliqué le succès de windows® par sa vivialité : tout y serait « Mme Michu compliant ». Mais dès qu'on tombe (rapidement) sur des petits problèmes qui seraient faciles à régler avec un unixoïde, on sombre très rapidement dans le shadokisme le plus abscons.
Et il n'existe pas de doc, ou alors en suivant un stage "Most Value Pigeon" à watt-mille brouzoufs pour bien te faire sentir, par la douloureuse, que tu es maintenant admis dans le saint des saints de la connaissance ultime du système : du marketing pour analphabètes de l'1-faux et autres techno-crétins.
Avec un unixoïde comme linux, on simplifie les choses au maximum de manière qu'il est évident qu'il n'y a pas de défaut. Avec windows®, on complexifie les choses le plus possible tel qu'il est impossible de trouver les défauts qui sinon seraient évidents.
[x-post et fu2 fourbe]
--
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car un clavier AZERTY en vaut 2.
pehache-youplaboum
"Hugolino" a écrit dans le message de news:
Le 14-10-2010, Hugues a écrit :
[...] Le truc, c'est qu'avec Unix c'est facile.
Sous windows, je n'ai jamais réussi à trouver un moyen de gérer les droits proprement, simplement, et sans que ça fasse chier tout le monde... C'était peut être facile, peut être pas, en tout cas ça n'a pas été clair pour moi dès le début.. [...]
+1
On a longtemps expliqué le succès de windows® par sa vivialité : tout y serait « Mme Michu compliant ». Mais dès qu'on tombe (rapidement) sur des petits problèmes qui seraient faciles à régler avec un unixoïde, on sombre très rapidement dans le shadokisme le plus abscons.
Ce n'est pas parce que tu n'y comprends rien que c'est difficile.
Avec les ACL à la Windows on peut se contenter de faire de la gestion simple des permissions, du type rwx. Et le premier niveau des réglages des permissions est fait pour ça. Ce n'est que si on clique sur "avancé" qu'on a accès à toutes les possibilités.
T'as encore perdu de te taire, gogolino.
Et il n'existe pas de doc,
Faux.
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir besoin de doc.
ou alors en suivant un stage "Most Value Pigeon" à watt-mille brouzoufs pour bien te faire sentir, par la douloureuse, que tu es maintenant admis dans le saint des saints de la connaissance ultime du système : du marketing pour analphabètes de l'1-faux et autres techno-crétins.
Il parle comme d'habitude de ce qu'il ne connait pas, gogolino. Il ne maîtrise pas les ACL, ne sait pas qu'il y une doc, donc c'est un truc de techno-crétins.
[x-post et fu2 fourbe]
Toujours aussi con. Aux chiottes le fu2.
-- pehache http://pehache.free.fr "Quand on n'a rien à faire avec un logiciel à part l'utiliser...", BR in fcold
"Hugolino" <hugolino@free.fr> a écrit dans le message de news:
slrnibf4le.c60.hugolino@Deborah.Rock-n-Roll.org
Le 14-10-2010, Hugues <hugues@hiegel.fr> a écrit :
[...]
Le truc, c'est qu'avec Unix c'est facile.
Sous windows, je n'ai jamais réussi à trouver un moyen de
gérer les droits proprement, simplement, et sans que ça fasse
chier tout le monde... C'était peut être facile, peut être pas, en
tout cas ça n'a pas été clair pour moi dès le début.. [...]
+1
On a longtemps expliqué le succès de windows® par sa vivialité : tout
y serait « Mme Michu compliant ».
Mais dès qu'on tombe (rapidement) sur des petits problèmes qui
seraient faciles à régler avec un unixoïde, on sombre très rapidement
dans le shadokisme le plus abscons.
Ce n'est pas parce que tu n'y comprends rien que c'est difficile.
Avec les ACL à la Windows on peut se contenter de faire de la gestion simple
des permissions, du type rwx. Et le premier niveau des réglages des
permissions est fait pour ça. Ce n'est que si on clique sur "avancé" qu'on a
accès à toutes les possibilités.
T'as encore perdu de te taire, gogolino.
Et il n'existe pas de doc,
Faux.
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir
besoin de doc.
ou alors en suivant un stage "Most Value
Pigeon" à watt-mille brouzoufs pour bien te faire sentir, par la
douloureuse, que tu es maintenant admis dans le saint des saints de la
connaissance ultime du système : du marketing pour analphabètes de
l'1-faux et autres techno-crétins.
Il parle comme d'habitude de ce qu'il ne connait pas, gogolino. Il ne
maîtrise pas les ACL, ne sait pas qu'il y une doc, donc c'est un truc de
techno-crétins.
[x-post et fu2 fourbe]
Toujours aussi con. Aux chiottes le fu2.
--
pehache
http://pehache.free.fr
"Quand on n'a rien à faire avec un logiciel à part l'utiliser...", BR
in fcold
Sous windows, je n'ai jamais réussi à trouver un moyen de gérer les droits proprement, simplement, et sans que ça fasse chier tout le monde... C'était peut être facile, peut être pas, en tout cas ça n'a pas été clair pour moi dès le début.. [...]
+1
On a longtemps expliqué le succès de windows® par sa vivialité : tout y serait « Mme Michu compliant ». Mais dès qu'on tombe (rapidement) sur des petits problèmes qui seraient faciles à régler avec un unixoïde, on sombre très rapidement dans le shadokisme le plus abscons.
Ce n'est pas parce que tu n'y comprends rien que c'est difficile.
Avec les ACL à la Windows on peut se contenter de faire de la gestion simple des permissions, du type rwx. Et le premier niveau des réglages des permissions est fait pour ça. Ce n'est que si on clique sur "avancé" qu'on a accès à toutes les possibilités.
T'as encore perdu de te taire, gogolino.
Et il n'existe pas de doc,
Faux.
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir besoin de doc.
ou alors en suivant un stage "Most Value Pigeon" à watt-mille brouzoufs pour bien te faire sentir, par la douloureuse, que tu es maintenant admis dans le saint des saints de la connaissance ultime du système : du marketing pour analphabètes de l'1-faux et autres techno-crétins.
Il parle comme d'habitude de ce qu'il ne connait pas, gogolino. Il ne maîtrise pas les ACL, ne sait pas qu'il y une doc, donc c'est un truc de techno-crétins.
[x-post et fu2 fourbe]
Toujours aussi con. Aux chiottes le fu2.
-- pehache http://pehache.free.fr "Quand on n'a rien à faire avec un logiciel à part l'utiliser...", BR in fcold
Sergio
Le 15/10/2010 01:30, Hugolino a écrit :
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car un clavier AZERTY en vaut 2.
Dans ces cas là, choisir le clavier "US-International" (ou "États-Unis International" ?). Les touches "accents" sont alors dead-keys. Et que ce que ce soit sous Windows ou Linux (Mac, j'ai aps testé...).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 15/10/2010 01:30, Hugolino a écrit :
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je
voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car
un clavier AZERTY en vaut 2.
Dans ces cas là, choisir le clavier "US-International" (ou "États-Unis International" ?). Les touches "accents" sont alors
dead-keys. Et que ce que ce soit sous Windows ou Linux (Mac, j'ai aps testé...).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
J'ai besoin des caracteres []{}|/~ (Clavier >> Anglais-US). Mais je voudrais bien pouvoir mettre des accents dans mes courriels en francais
Il te faut donc trouver un clavier qui fait les 2. Prends l'azerty, car un clavier AZERTY en vaut 2.
Dans ces cas là, choisir le clavier "US-International" (ou "États-Unis International" ?). Les touches "accents" sont alors dead-keys. Et que ce que ce soit sous Windows ou Linux (Mac, j'ai aps testé...).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Hugues
"pehache-youplaboum" a suggéré :
Bien sûr, on peut rendre les ACL totalement bordéliques si on fait n'importe quoi, mais c'est vrai aussi en mulitpliant les groupes.
Voilà.
Quant à la gestion de plusieurs groupes distincts, je ne vois pas trop le problème : ça ne change pas grand chose dans l'un ou l'autre cas... Car même avec la gestion "fine", tu es obligé de distinguer plusieurs groupes d'utilisateurs, et de gérer des droits en fonction...
Avec les ACL la structure des groupes peut se calquer sur l'organisation hiérarchique de l'entreprise, par l'exemple. Une personne change de service, hop elle change de groupe, et toutes les permissions associées sont d'un coup mises à jour. Avec les groupes Unix c'est impossible.
Euh, tu m'expliques la différence entre changer un utilisateur de groupe avec les ACL, ou avec les basiques groupes Unix !?? C'est strictement du pareil au même ....
La seule différence entre les ACL et les groupes UNIX, est que pour l'accès aux fichiers / dossiers du système, pour les groupes UNIX tu n'as que 3 niveaux possibles : le propriétaire, le groupe du fichier/dossier (un seul, donc), et les autres.
avec les ACLS, tu mets autant de propriétaires et de groupes que tu veux à un fichier/dossier donné.
C'est la SEULE différence.
Et elle induit beaucoup de choses :
- avec la méthode "simple", tu détermines les droits d'accès à une ressource donnée en déterminant strictement un groupe d'utilisation pour la ressource. (souvent confondu avec le propriétaire, notamment dans le cas des services système). Toute personne à qui tu veux donner accès à la ressource donnée, tu as juste à l'intégrer dans le groupe donné. point.
- avec les ACL, pour chaque ressource, tu vas attribuer des droits à un groupe donné, d'autres à un autre groupe, et etc...
Dans le premier cas, qui correspont à un schéma de 99% de cas d'utilisations (tiens c'est bizarre, le même argument que "windows c'est bien car 99% des gens l'utilisent..."), une ressource est clairement identifiée par un groupe, et un seul.
Avec les ACLs, tu as un nombre indéfini de groupes par ressources. Bonjour pour t'y retrouver....
En fait, dans le premier cas, tu gères les droits d'accès au niveau du répertoire des utilisateurs/groupes en grande partie (rajouter tel ou tel utilisateur dans tel ou tel groupe), et en petite partie au niveau de la ressource (donner les droits à tel propriétaire/groupe/autres)
Dans le second, tu gères les droits d'accès au niveau du répertoire en moyenne partie (rajouter tel ou tel utilisateur dans tel ou tel groupe, certes un peu moins que dans le premier cas.. mais quand même dans un certain nombre de groupes..), et au niveau de la ressource en grande partie aussi (gérer les droits de tel ou tel utilisateur, et de tel ou tel groupe...). AMha, tu as plus vite fait d'oublier un utilisateur ou un groupe donné dans un répertoire donné avec ce système...
Dans les deux cas, si tu un utilisateur change de statut, tu le vires des groupes desquels il n'a plus rien à faire. Avec une moyenne d'une vingtaine de groupe à tout casser, c'est vraiment pas la mer à boire, surtout quand les ajouts/suppressions d'utilisateurs sur les gros parcs sont gérés par des scripts qui font ce boulot ...
En fait, moi, j'aimerais un système entre les deux : un système de meta-groupes, dans lequel un groupe (et donc ses membres) pourrait être membre d'un autre groupe. Ça simplifierait un peu le schéma (pas la peine de rajouter X utilisateurs d'un groupe A et Y utilisateurs d'un groupe B dans un groupe C, mais seulement un groupe A et un groupe B dans le groupe C. Et si tu supprimes l'utilisateur a' du groupe A, il n'est automatiquement plus dans le groupe C..)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
"pehache-youplaboum" <pehache.7@gmail.com> a suggéré :
Bien sûr, on peut rendre les ACL totalement bordéliques si on fait
n'importe quoi, mais c'est vrai aussi en mulitpliant les groupes.
Voilà.
Quant à la gestion de plusieurs groupes distincts, je ne vois pas
trop le problème : ça ne change pas grand chose dans l'un ou
l'autre cas... Car même avec la gestion "fine", tu es obligé de
distinguer plusieurs groupes d'utilisateurs, et de gérer des droits
en fonction...
Avec les ACL la structure des groupes peut se calquer sur
l'organisation hiérarchique de l'entreprise, par l'exemple. Une
personne change de service, hop elle change de groupe, et toutes les
permissions associées sont d'un coup mises à jour. Avec les groupes
Unix c'est impossible.
Euh, tu m'expliques la différence entre changer un utilisateur de groupe
avec les ACL, ou avec les basiques groupes Unix !??
C'est strictement du pareil au même ....
La seule différence entre les ACL et les groupes UNIX, est que pour
l'accès aux fichiers / dossiers du système, pour les groupes UNIX tu
n'as que 3 niveaux possibles : le propriétaire, le groupe du
fichier/dossier (un seul, donc), et les autres.
avec les ACLS, tu mets autant de propriétaires et de groupes que tu veux
à un fichier/dossier donné.
C'est la SEULE différence.
Et elle induit beaucoup de choses :
- avec la méthode "simple", tu détermines les droits d'accès à une
ressource donnée en déterminant strictement un groupe d'utilisation
pour la ressource. (souvent confondu avec le propriétaire, notamment
dans le cas des services système).
Toute personne à qui tu veux donner accès à la ressource donnée, tu as
juste à l'intégrer dans le groupe donné. point.
- avec les ACL, pour chaque ressource, tu vas attribuer des droits à un
groupe donné, d'autres à un autre groupe, et etc...
Dans le premier cas, qui correspont à un schéma de 99% de cas
d'utilisations (tiens c'est bizarre, le même argument que "windows c'est
bien car 99% des gens l'utilisent..."), une ressource est clairement
identifiée par un groupe, et un seul.
Avec les ACLs, tu as un nombre indéfini de groupes par
ressources. Bonjour pour t'y retrouver....
En fait, dans le premier cas, tu gères les droits d'accès au niveau du
répertoire des utilisateurs/groupes en grande partie (rajouter tel ou
tel utilisateur dans tel ou tel groupe), et en petite partie au niveau
de la ressource (donner les droits à tel propriétaire/groupe/autres)
Dans le second, tu gères les droits d'accès au niveau du répertoire en
moyenne partie (rajouter tel ou tel utilisateur dans tel ou tel groupe,
certes un peu moins que dans le premier cas.. mais quand même dans un
certain nombre de groupes..), et au niveau de la ressource en grande
partie aussi (gérer les droits de tel ou tel utilisateur, et de tel ou
tel groupe...). AMha, tu as plus vite fait d'oublier un utilisateur ou
un groupe donné dans un répertoire donné avec ce système...
Dans les deux cas, si tu un utilisateur change de statut, tu le vires
des groupes desquels il n'a plus rien à faire. Avec une moyenne d'une
vingtaine de groupe à tout casser, c'est vraiment pas la mer à boire,
surtout quand les ajouts/suppressions d'utilisateurs sur les gros parcs
sont gérés par des scripts qui font ce boulot ...
En fait, moi, j'aimerais un système entre les deux : un système de
meta-groupes, dans lequel un groupe (et donc ses membres) pourrait être
membre d'un autre groupe. Ça simplifierait un peu le schéma (pas la
peine de rajouter X utilisateurs d'un groupe A et Y utilisateurs d'un
groupe B dans un groupe C, mais seulement un groupe A et un groupe B
dans le groupe C. Et si tu supprimes l'utilisateur a' du groupe A, il
n'est automatiquement plus dans le groupe C..)
Bien sûr, on peut rendre les ACL totalement bordéliques si on fait n'importe quoi, mais c'est vrai aussi en mulitpliant les groupes.
Voilà.
Quant à la gestion de plusieurs groupes distincts, je ne vois pas trop le problème : ça ne change pas grand chose dans l'un ou l'autre cas... Car même avec la gestion "fine", tu es obligé de distinguer plusieurs groupes d'utilisateurs, et de gérer des droits en fonction...
Avec les ACL la structure des groupes peut se calquer sur l'organisation hiérarchique de l'entreprise, par l'exemple. Une personne change de service, hop elle change de groupe, et toutes les permissions associées sont d'un coup mises à jour. Avec les groupes Unix c'est impossible.
Euh, tu m'expliques la différence entre changer un utilisateur de groupe avec les ACL, ou avec les basiques groupes Unix !?? C'est strictement du pareil au même ....
La seule différence entre les ACL et les groupes UNIX, est que pour l'accès aux fichiers / dossiers du système, pour les groupes UNIX tu n'as que 3 niveaux possibles : le propriétaire, le groupe du fichier/dossier (un seul, donc), et les autres.
avec les ACLS, tu mets autant de propriétaires et de groupes que tu veux à un fichier/dossier donné.
C'est la SEULE différence.
Et elle induit beaucoup de choses :
- avec la méthode "simple", tu détermines les droits d'accès à une ressource donnée en déterminant strictement un groupe d'utilisation pour la ressource. (souvent confondu avec le propriétaire, notamment dans le cas des services système). Toute personne à qui tu veux donner accès à la ressource donnée, tu as juste à l'intégrer dans le groupe donné. point.
- avec les ACL, pour chaque ressource, tu vas attribuer des droits à un groupe donné, d'autres à un autre groupe, et etc...
Dans le premier cas, qui correspont à un schéma de 99% de cas d'utilisations (tiens c'est bizarre, le même argument que "windows c'est bien car 99% des gens l'utilisent..."), une ressource est clairement identifiée par un groupe, et un seul.
Avec les ACLs, tu as un nombre indéfini de groupes par ressources. Bonjour pour t'y retrouver....
En fait, dans le premier cas, tu gères les droits d'accès au niveau du répertoire des utilisateurs/groupes en grande partie (rajouter tel ou tel utilisateur dans tel ou tel groupe), et en petite partie au niveau de la ressource (donner les droits à tel propriétaire/groupe/autres)
Dans le second, tu gères les droits d'accès au niveau du répertoire en moyenne partie (rajouter tel ou tel utilisateur dans tel ou tel groupe, certes un peu moins que dans le premier cas.. mais quand même dans un certain nombre de groupes..), et au niveau de la ressource en grande partie aussi (gérer les droits de tel ou tel utilisateur, et de tel ou tel groupe...). AMha, tu as plus vite fait d'oublier un utilisateur ou un groupe donné dans un répertoire donné avec ce système...
Dans les deux cas, si tu un utilisateur change de statut, tu le vires des groupes desquels il n'a plus rien à faire. Avec une moyenne d'une vingtaine de groupe à tout casser, c'est vraiment pas la mer à boire, surtout quand les ajouts/suppressions d'utilisateurs sur les gros parcs sont gérés par des scripts qui font ce boulot ...
En fait, moi, j'aimerais un système entre les deux : un système de meta-groupes, dans lequel un groupe (et donc ses membres) pourrait être membre d'un autre groupe. Ça simplifierait un peu le schéma (pas la peine de rajouter X utilisateurs d'un groupe A et Y utilisateurs d'un groupe B dans un groupe C, mais seulement un groupe A et un groupe B dans le groupe C. Et si tu supprimes l'utilisateur a' du groupe A, il n'est automatiquement plus dans le groupe C..)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
"pehache-youplaboum" a suggéré :
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir besoin de doc.
Excuse-moi de trouver "Contrôle total / Modification / Lecture et exécution / Affichage du contenu du dossier / Lecture / Écriture / Autorisations spéciales" avec un "Autoriser/Refuser" plus compliqué que "RWX", surtout que quand tu cliques sur un Autoriser ou un Refuser, t'as plein d'autres Autoriser/Refuser qui changent automatiquement ...
Désolé mais non, non, et non. Ce n'est pas clair, pas trivial du tout.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
"pehache-youplaboum" <pehache.7@gmail.com> a suggéré :
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir
besoin de doc.
Excuse-moi de trouver "Contrôle total / Modification / Lecture et
exécution / Affichage du contenu du dossier / Lecture / Écriture /
Autorisations spéciales" avec un "Autoriser/Refuser" plus compliqué que
"RWX", surtout que quand tu cliques sur un Autoriser ou un Refuser, t'as
plein d'autres Autoriser/Refuser qui changent automatiquement ...
Désolé mais non, non, et non. Ce n'est pas clair, pas trivial du tout.
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir besoin de doc.
Excuse-moi de trouver "Contrôle total / Modification / Lecture et exécution / Affichage du contenu du dossier / Lecture / Écriture / Autorisations spéciales" avec un "Autoriser/Refuser" plus compliqué que "RWX", surtout que quand tu cliques sur un Autoriser ou un Refuser, t'as plein d'autres Autoriser/Refuser qui changent automatiquement ...
Désolé mais non, non, et non. Ce n'est pas clair, pas trivial du tout.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
Hugues a suggéré :
"pehache-youplaboum" a suggéré :
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir besoin de doc.
Excuse-moi de trouver "Contrôle total / Modification / Lecture et exécution / Affichage du contenu du dossier / Lecture / Écriture / Autorisations spéciales" avec un "Autoriser/Refuser"
En fait , c'est "Autoriser/Refuser/ ou rien" !!! ....
plus compliqué que "RWX", surtout que quand tu cliques sur un Autoriser ou un Refuser, t'as plein d'autres Autoriser/Refuser qui changent automatiquement ...
Désolé mais non, non, et non. Ce n'est pas clair, pas trivial du tout.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues <hugues@hiegel.fr> a suggéré :
"pehache-youplaboum" <pehache.7@gmail.com> a suggéré :
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir
besoin de doc.
Excuse-moi de trouver "Contrôle total / Modification / Lecture et
exécution / Affichage du contenu du dossier / Lecture / Écriture /
Autorisations spéciales" avec un "Autoriser/Refuser"
En fait , c'est "Autoriser/Refuser/ ou rien" !!! ....
plus compliqué que
"RWX", surtout que quand tu cliques sur un Autoriser ou un Refuser, t'as
plein d'autres Autoriser/Refuser qui changent automatiquement ...
Désolé mais non, non, et non. Ce n'est pas clair, pas trivial du tout.
Mais de toutes façons la GUI est suffisamment claire pour ne pas avoir besoin de doc.
Excuse-moi de trouver "Contrôle total / Modification / Lecture et exécution / Affichage du contenu du dossier / Lecture / Écriture / Autorisations spéciales" avec un "Autoriser/Refuser"
En fait , c'est "Autoriser/Refuser/ ou rien" !!! ....
plus compliqué que "RWX", surtout que quand tu cliques sur un Autoriser ou un Refuser, t'as plein d'autres Autoriser/Refuser qui changent automatiquement ...
Désolé mais non, non, et non. Ce n'est pas clair, pas trivial du tout.
