Ouip

• [^]Re: Ouip

  Posté par L () le 11/08/2004 à 09:42. (lien). Évalué à 2.

  Les droits "ancestraux" d'Unix ont l'avantage de permettre en un seul listing simple (dans le style de celui de la commande "tar tvzf archive.tar.gz") d'avoir une vue d'ensemble conscise et simple des droits d'accès d'une arborescence donnée. Personnellement, c'est quelque chose que j'apprécie vraiment.

  • [^]Re: Ouip

    Posté par cho7 (page perso, ) le 11/08/2004 à 16:28. (lien). Évalué à 1.

    'Ancestraux' n'est pas péjoratif.
    Je n'ai pas critiqué gratuitement ces droits, mais comme tu le dis toi meme, ils sont simples.
    Pour la gestion de droit avancé sans se prendre la tete les acl sont bien mieux, quoique t'en penses. Maintenant pour les 3/4 des users, rwx pour u g o a c'est nettement suffisant, et auquel cas, le fait d'activer les acl pour une partition n'oblige absolument pas l'utilisateur a les utiliser. il peut ainsi y avoir recours dans des cas exceptionnel, là ou il se rendra compte que plutot que de se prendre la tete, il peut utiliser les acl.
    
    voilà tout.

    --
    le python, c'est bon

• [^]Re: Ouip

  Posté par nicodache () le 11/08/2004 à 09:42. (lien). Évalué à 3.

  ya des droits sous windoze ?
  
  plus sérieusement, en fat32, les droits c'est un peu n'importe quoi, et en ntfs, j'y ai jamais rien pigé, contrairement au chmod ugo+/-rwx ancestral de unix... ;)
  
  m'enfin, c'est quand même bien de mettre le lien :)

  --
  Gougueul bombons ensemble :)

  • [^]Re: Ouip

    Posté par Krunch (Jabber id, page perso, ) le 11/08/2004 à 12:47. (lien). Évalué à 2.

    J'ai entendu dire quelque part que sous NT/2k/XP, yavait moyen de mettre des droits "complexes" genre ACL sur "tout" et donc qu'il était possible de régler les droits d'accès beaucoup plus finement que sous *nix. Le problème c'est que c'est plus compliqué à mettre en place que de s'amuser avec chmod et que donc pratiquement personne ne le faisait. Enfin c'est ce que j'ai lu quelque part, si un Windowsien peut {in|con}firmer...

    --
    Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
    pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

    • [^]Re: Ouip

      Posté par Éric (Jabber id, page perso, ) le 11/08/2004 à 21:45. (lien). Évalué à 3.

      Compliqué ? tu cliques droit, propriétés, puis à un moment si tu ne l'as jamais fait il te faudra cliquer sur "avancé" ou "activer les droits d'accès complexes", ou un truc du genre (me souviens plus, désolé). Là tu peut ajouter/retirer des utilisateurs par leur nom (via une interface tout ce qu'il y a de simple).
      
      De ce coté ce qui est "complexe" ce n'est pas l'interface, c'est la notion d'utilisateur et droit d'accès. Si tu es capable de comprendre la gestion des droits Unix les ACL Windows te seront comprehensibles en 2 minutes chrono en main. Quand tu valides sur un dossier il te demande si il doit faire les modifs récursivement sur les sous dossiers et fichiers. Je crois même que tu as une coche pour définir si les droits sont héritables ou pas (à vérifier).
      
      Franchement c'est effectivement un point où Win a de l'avance (je met "a" et non "avait" car pour moi ça sera bon quand les ACL seront répandues et gérées par tous les softs qui manipulent les droits d'accès, principalement les explorateurs de fichier).

Cette hiérarchie à trois niveaux suffit

• [^]Re: Cette hiérarchie à trois niveaux suffit

  Posté par Éric (Jabber id, page perso, ) le 11/08/2004 à 21:46. (lien). Évalué à 2.

  Oui, mais ce n'est pas parfait. Parce que quand mon copain écrira ses fichiers ils appartiendront par défaut à son groupe par défaut, pas à notre groupe commun.
  Il y a trois paliatif :
  - une commande qui permet de changer le groupe effectif pour que mon copain puisse prendre l'identité du groupe pendant sa session de travail sur le dossier commun. J'ai remarqué que l'outil en question était très peu connu, ne marchait pas sur toutes les distrib (voire n'était pas présent) mais bon, au mieux ça demande une manipulation explicite manuelle, puis de revenir à l'état précédent une fois qu'il a finit de manipuler les fichiers communs : non satisfaisant.
  - changer le groupe à chaque fois après avoir écrit les fichiers dans le répertoire commun. C'est vite lourd et on a vite fait d'oublier.
  - faire un setgid sur le répertoire, ce qui a d'autres implications et n'est pas toujours satisfaisant non plus.
  
  Bref, il manque l'héritage des ACL, qui est bien pratique pour ce cas là justement.

• [^]Re: Cette hiérarchie à trois niveaux suffit

  Posté par Jerome Herman () le 12/08/2004 à 08:23. (lien). Évalué à 2.

  L'exemple donné dans le texte n'est pas le bon.
  On rencontre la vrai limite des droits Unix dans le cas suivant :
  On veut un groupe en execution seule sur un repertoire (les utilisateurs) et un groupe en lecture/ecriture/execution (les admins du programe). Ben là ca devient complexe. Bonjour la floraison de SetUID et de SetGID....
  Si dérrière il faut un groupe en lecture/execution (pour l'audit) et un groupe en lecture seule (pour les back-ups) c'est carrément la fête au village.
  
  Kha

  --
  Kha
  root est un privilège, pas un droit !

Precision