Problèmes d'autorisations

[footix82]

Pour résoudre le pb de manière radicale, et être sur de ne rien oublier, on peut faire la chose suivante dans un répertoire :

CODE

find . -exec chmod -a "everyone deny delete" {} \;

ce qui va lancer la commande chmod sur chaque fichier et sous repertoire du repertoire courant. On aura plein de messages "chmod: No ACL present" ; mais on est sur que pour les fichiers/repertoires qui avaient cette entrée dans leur ACL, elle sera supprimée .

Merci Darenzana, ca marche du tonnerre

[Macoupc]

Le sudo ne devrait pas être nécessaire, l'utilisateur yoann s'est deja approprié l'ensemble de ses fichiers (Message 9).
ça veut dire quoi "il y a 2 fois Yoann"? Dans les infos du finder, ou dans un ls -l? Comme l'indique Rigodon, certains dossiers doivent toujours avoir comme groupe Yoann. Mais normalement il devraient tous être dans le groupe staff, vu la commande chgrp effectuée auparavant...

Grâce à la commande "everyone any delete" la plupart des fichiers sont dans le groupe staff.

Il y a 2 fois yoann dans les infos du finder pour quelques applications... Ça fait pas propre. Et quand j'essaie "à la main" dans le finder d'ajouter le groupe "staff" par exemple, ça ne marche pas et ça relance le finder sans que j'ai rien demandé...


Je peux "disposer" de mes fichiers mais je dois pour les applications par exemple, taper mon mot de passe admin si je veux les supprimer. Ça pose des problèmes aussi pour certaines mises à jour qui refusent de s'installer, sûrement car le protocole "demander mot de passe" n'a pas été programmé.

[Perklo]

Bonjour,

Voilà l'ignorant de service...

J'aimerais savoir à quoi correspond le groupe "staff" exactement. Quels sont les utilisateurs qui lui appartiennent? Quels sont les prérogatives de ce groupe?

Merci :-)

[steenux]

Bonjour,

J'ai ouvert un autre fil sur le même sujet avant de trouver celui là :
http://forum.macbidouille.com/index.php?showtopic=246963#

Je pense avoir trouvé les réponses pour copier les fichiers récalcitrants et enfin récupérer mes bibliothèques.
Je les essayes dès a\que je rentre chez moi.

Toute cette lecture est très interressante et instructive, mais attention, on peut faire plus de dégat que de réparation

[Macoupc]

Bonjour,

J'ai ouvert un autre fil sur le même sujet avant de trouver celui là :
http://forum.macbidouille.com/index.php?showtopic=246963#

Je pense avoir trouvé les réponses pour copier les fichiers récalcitrants et enfin récupérer mes bibliothèques.
Je les essayes dès que je rentre chez moi.

Toute cette lecture est très interressante et instructive, mais attention, on peut faire plus de dégat que de réparation

C'est étrange, t'as la même image d'avatar qu'un autre membre du forum (que je ne connais pas plus que ça) mais les questions que tu poses paraissaient un peu trop évidentes pour ce membre... Enfin voilà, remarque inutile.

[steenux]

Désolé pour l'avatar, mais quand je me suis inscrit sur le site, il me plaisait bien et était dispo sur le site...

[steenux]

Bonsoir,

En cherchant des infos sur l'utilisation des ACL, j'ai lu sur un site que de faire une archive .tar enlevait les ACL sur les fichiers et dossiers.

Je ne sais pas si c'est exact, mais j'ai enfin pu récupérer mes photos et musiques sauvegardées sur un disque externe en créant un .tar.gz sur le disque interne et réimportations dans les bibliothèques iTunes et iPhotos sans problème.

Si sa peut en aider d'autre...

EDIT : Voici le lien <http://www.commentcamarche.net/faq/sujet-3773-securite-les-access-control-lists-acls>

Ce message a été modifié par steenux - 9 Dec 2007, 15:28.

[Joël Pierre]

J’ai aussi des problème bizarres avec les autorisations de Leopard. Tous le contenu de mes dossiers utilisateur privés (Bibliothèque, Documents, Images, Musique, Séquences) ne peuvent être mis à la corbeille que si je donne mon mot de passe de session (je suis administrateur). Les nouveaux fichiers créés dans ces dossiers peuvent en revanche être mis à la corbeille sans autorisation. J’ai réparé à plusieurs reprises les autorisations (avec Utilitaire de disque et Terminal) sans aucun changement. J’ai aussi des problème avec les préférences de Photoshop (en quittant, un message me dit que les préférences n’ont pu être enregistrées, faute de droit suffisants). J’ai déjà supprimé les fichiers de préférences de Photoshop (les nouveaux fichiers se laissant modifier). Mais après quelques temps, rebelote.

Comment devraient être les droits sur ces dossiers ?

[Rigodon]

Si le système te demande ton mot de passe c'est que tu n'es pas propriétaire des fichiers, donc il te faut des droits root(que tu as en étant dans le groupe admin). Décris-nous ta méthode d'installation de Leopard.

[Joël Pierre]

Si le système te demande ton mot de passe c'est que tu n'es pas propriétaire des fichiers, donc il te faut des droits root(que tu as en étant dans le groupe admin). Décris-nous ta méthode d'installation de Leopard.

Mais si je suis propriétaire des fichiers et dossiers (un cmd I sur chacun me le confirme). Et c'est justement pour cela qu'il me demande de confirmer mes droits (comme les installateurs de logiciels).

J’ai fait mon installation de manière très orthodoxe avec le DVD d’installation sur une partition effacée au préalable.

J’ajoute que j’ai eu les même soucis sur une autre partition qui ne possède pas de système et dont les droits ne sont théoriquement pas gérés. Puisque que le système (Utilitaire de disque ou Terminal sont incapables de rétablir des droits conformes, je vous demande comment le faire manuellement avec Batchmod.

Quels devraient donc être théoriquement les R W X pour le Possesseur (Moi), Groupe (staff) et Tous (everyone) ?

Ce message a été modifié par Joël Pierre - 2 Jan 2008, 22:57.

[darenzana]

Bonjour,
je pense que ton problème est lié aux droits étendus, et Batchmod ne pourra pas t'aider dans ce cas.
Ouvre un Terminal, et tape dedans la commande:

CODE

ls -le Documents

et colle le résultat ici.

si tu vois des "everyone deny delete" ton probleme est bien lié aux ACL, et il te faudra utiliser la commande find que je donne en haut de cette page.
Pour les détails tu peux lire ce message.

Ce message a été modifié par darenzana - 2 Jan 2008, 23:15.

[Joël Pierre]

Je pense que ton problème est lié aux droits étendus, et Batchmod ne pourra pas t'aider dans ce cas.
Ouvre un Terminal, et tape dedans la commande:

CODE

ls -le Documents

et colle le résultat ici. Si tu vois des "everyone deny delete" ton probleme est bien lié aux ACL, et il te faudra utiliser la commande find que je donne en haut de cette page.

C’est bien cela . J’ai fait find . -exec chmod -a "everyone deny delete" {} \; comme préconisé et j’ai les 0: group:everyone deny delete

En faisant find . -exec chmod -a "everyone deny delete" {} \;, j’ai plein de chmod: No ACL present et quelques chmod: Failed to set ACL on file './Documents/xxxxxx.xxx': Operation not permitted sur des fichiers verrouillés. Et un chmod: Entry not found when attempting delete

Tout semble apparement revenu à la normale.

Merci.

J’ai refais ensuite une réparation des autorisations avec Utilitaire de disque.

Voici ce qu’il trouve :

ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.
Le groupe est différent sur « Library/PreferencePanes », il devrait être 0 au lieu de 80.
Les autorisations sont différentes sur « Library/PreferencePanes », elles devraient être drwxr-xr-x au lieu de drwxrwxr-x .
ACL trouvé mais non prétendu sur « Library ».
Pour ARDAgent, cela semble un bug d’Apple, mais les pour Preferences Panes ?
Et un ACL trouvé mais non prétendu. Qu’est-ce ?



Ce message a été modifié par Joël Pierre - 3 Jan 2008, 10:29.

[darenzana]

Il me semble que la réparation des autorisations ne touche pas aux fichier de ton dossier utilisateur, mais uniquement aux fichiers système, donc je pense que les messages que tu obtiens ne sont pas liés au problème précédent...

Tu as probablement installé un logiciel qui ajoute un module dans les préférences, et qui a modifié les droits sur le répertoire "/Library/PrerencePanes" ce faisant. Et donc la réparation des autorisations a corrigé ce point.

Pour le "ACL trouvé mais non prétendu" je ne sais pas trop.. Que donne 'ls -led /Library' ?

[Joël Pierre]

Pour le "ACL trouvé mais non prétendu" je ne sais pas trop.. Que donne 'ls -led /Library' ?

G5:~ joel$ ls -led /Library
drwxrwxr-t@ 65 root admin 2210 2 jan 15:31 /Library
0: group:everyone deny delete

[darenzana]

J'ai les mêmes droits sur /Library... On va dire que c'est pas grave non plus.

[steenux]

Moi, je n'ai pas exactement les mêmes droits que vous, par contre, OK pour les ACL.

Voila le résultat d'un ls -le sur mon répertoire home :
iMac:~ steve$ lle
rwx------+ 4 steve staff 136 2 jan 12:13 Desktop/
0: group:everyone deny delete
drwx------+ 51 steve staff 1734 30 déc 17:01 Documents/
0: group:everyone deny delete
drwx------+ 22 steve staff 748 5 jan 09:53 Downloads/
0: group:everyone deny delete
drwx------+ 47 steve staff 1598 30 déc 17:05 Library/
0: group:everyone deny delete
drwx------+ 7 steve staff 238 29 déc 18:35 Movies/
0: group:everyone deny delete
drwx------+ 5 steve staff 170 9 déc 11:05 Music/
0: group:everyone deny delete
rwx------+ 6 steve staff 204 22 déc 14:44 Pictures/
0: group:everyone deny delete
drwxr-xr-x+ 6 steve staff 204 6 déc 23:44 Public/
0: group:everyone deny delete
drwxr-xr-x+ 5 steve staff 170 6 déc 17:00 Sites/
0: group:everyone deny delete

A part "Sites" et "Public", les autres répertoires ont des droits à 700+ alors que les vôtres sont à 77?@

Apparemment, les miens sont plus restrictifs mais je ne connais pas la signification du "t@" à la fin de tes droits.

--EDIT--

Après une recherche sur le net, le "t" à la fin des droits indique qu'un "Sticky bit" est positionné sur le répertoire. Il permet d'interdire à tout utilisateur (sauf le root) de supprimer un fichier dont il n'est pas le propriétaire, quelque soient ses droits.
Je trouve que c'est un peu redondant avec les ACL qui indiquent que personne du groupe ne peut supprimer de fichiers ...

Mon répertoire Library/Preferences à les mêmes droits que mes autres répertoires :
rwx------+ 141 steve staff 4794 5 jan 17:54 Preferences/
0: group:everyone deny delete


Je retourne faire une recherche sur la signification du "+" et "@". Je crois que ça va avec les ACL mais je n'en suis pas sure.

Ce message a été modifié par steenux - 5 Jan 2008, 18:19.

[darenzana]

Moi, je n'ai pas exactement les mêmes droits que vous, par contre, OK pour les ACL.

Voila le résultat d'un ls -le sur mon répertoire home :

A part "Sites" et "Public", les autres répertoires ont des droits à 700+ alors que les vôtres sont à 77?@

Apparemment, les miens sont plus restrictifs mais je ne connais pas la signification du "t@" à la fin de tes droits.

Tu parles des répertoires de ton home, alors qu'on parlait du répertoire /Library, situé à la racine, et pas dans un home utilisateur.
Les droits sont effectivement plus restreints dans les répertoires utilisateurs.
Le 't' indique que le 'sticky-bit' est positionné, ce qui change le comportement lors de l'effacement d'un fichier,
et le @ indique des attributs positionnés (par le Finder en général).

[steenux]

Exact, j'avais mal lu, je possède bien les mêmes droits que vous sur /Library.

Désolé pour le bruit

[Rigodon]

Le + veut dire qu'une acl existe sur le fichier ou dossier. Par défaut Leo met les droits du home sur 700 en everyone deny delete. Donc tu es ok.

[darenzana]

Après une recherche sur le net, le "t" à la fin des droits indique qu'un "Sticky bit" est positionné sur le répertoire. Il permet d'interdire à tout utilisateur (sauf le root) de supprimer un fichier dont il n'est pas le propriétaire, quelque soient ses droits.
Je trouve que c'est un peu redondant avec les ACL qui indiquent que personne du groupe ne peut supprimer de fichiers ...

Ce n'est pas redondant, l'ACL 'everyone deny delete' est positionnée sur le répertoire /Library, et pas sur les fichiers qui sont dedans (elle n'est pas héritée). Donc elle interdit juste à tout le monde d'effacer le répertoire /Library, mais pas ses fichiers. Un membre du groupe admin pourrait effacer n'importe quel fichier ou répertoire à l'intérieur de /Library (sans utiliser sudo) si le bit t n'était pas positionné. Et si on faisait hériter l'ACL everyone deny delete au contenu de /Library, on n'aurait pas non plus le comportement voulu, puisque même le propriétaire d'un fichier ne pourrait pas l'effacer.

[steenux]

OK, merci pour ces explications.

Je pense comprendre un peu mieux les ACL. Si je me résume, une ACL agit sur le répertoire et uniquement lui, alors que le sticky bit agit sur les fichiers contenus dans ce répertoire ?


Je cherche toujours la signification du @ et + à la fin de l'information sur les droits.
J'ai bien trouvé que le + indiquait que le fichier ou le répertoire avait des droits étendus.
En lisant le man ls de léo, je crois comprendre que le @ veut dire qu'il y a des attributs étendus alors que le + indique une information de sécurité étendu ???

Je ne comprends pas bien la différence. Je vois bien la signification du + mais Darenzana m'indique que le @ indique des attributs positionnés (par le Finder en général). Et là, je ne comprends pas bien à quoi ça correspond ?

[darenzana]

Je pense comprendre un peu mieux les ACL. Si je me résume, une ACL agit sur le répertoire et uniquement lui, alors que le sticky bit agit sur les fichiers contenus dans ce répertoire ?

En ce qui concerne le répertoire /Library, oui.
Dans le cas général, une ACL peut contenir des droits qui seront hérités par les fichiers contenus dans le répertoire, tout dépend de ce qu'on veut faire. Apple a mis en ligne un dossier très complet sur ce sujet et d'autres : "File Services Administration" (en anglais). Le chapitre 2 "setting up file service permissions" est très instructif.
Le fichier pdf : http://images.apple.com/server/macosx/docs...Admin_v10.5.pdf

Je ne comprends pas bien la différence. Je vois bien la signification du + mais Darenzana m'indique que le @ indique des attributs positionnés (par le Finder en général). Et là, je ne comprends pas bien à quoi ça correspond ?

Par exemple, quand un répertoire doit être invisible dans le Finder, le système positionne le flag 'hidden' sur ce répertoire. Ce flag est stocké dans l'attibut "com.apple.FindeInfo" qui est alors attribué au fichier. Si on prend le cas de /usr, on peut le voir comme ça :

CODE

$ ls -led /usr
drwxr-xr-x@ 13 root  wheel  442 13 déc 02:28 /usr/

Le '@' m'indique des attributs étendus. Quels sont ils?

CODE

ls -l@d /usr
drwxr-xr-x@ 13 root  wheel  442 13 déc 02:28 /usr/
    com.apple.FinderInfo     32

Il y a donc un attribut "com.apple.FinderInfo" de taille 32. Continuons les recherches:

CODE

ls -lOd /usr
drwxr-xr-x@ 13 root  wheel  hidden 442 13 déc 02:28 /usr/

On voit que le flag hidden est positionné.
Pour aller plus loin, on peut aussi utiliser xattr:

CODE

$ xattr -l /usr
com.apple.FinderInfo:
0000   00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00    ........@.......
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

xattr "dumpe" le contenu de l'attribut. On peut conclure des résulats précédents que le flag hidden est situé à l'octet numero 8 dans l'attribut com.apple.FinderInfo.

Un autre exemple:
Je créé dans mon répertoire Documents un fichier toto.txt, avec TextEdit:

CODE

ls -l@ toto.txt
-rw-r--r--@ 1 didier  didier  6  6 jan 13:50 toto.txt
    com.apple.TextEncoding    15

Mon fichier contient déja un attribut "com.apple.TextEncoding", de taille 15. Cet attribut contient le contenu du champ "Encodage format Texte" que l'on renseigne au moment de l'enregistrement.

CODE

xattr -l toto.txt
com.apple.TextEncoding: UTF-8;134217984

On voit que j'ai choisi "UTF-8" comme encodage.
Maintenant, je fais pomme-I sur le fichier dans le Finder, et lui attribue une étiquette rouge.
de retour dans le Terminal, je regarde à nouveau mon fichier :

CODE

$ ls -l@ toto.txt
-rw-r--r--@ 1 didier  didier  6  6 jan 13:50 toto.txt
    com.apple.FinderInfo    32
    com.apple.TextEncoding    15

Il y a toujours l'attribut com.apple.TextEncoding, et un attribut com.apple.FinderInfo a été ajouté. Voyons son contenu:

CODE

$ xattr -pl com.apple.FinderInfo toto.txt
com.apple.FinderInfo:
0000   00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00    ................
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Donc l'étiquette 'Rouge' correspond à la valeur '0C' stockée dans l'octet numero 9 de l'atribut com.apple.FinderInfo.

Ce message a été modifié par darenzana - 6 Jan 2008, 14:02.

[stefhan]

Bonjour,

Je viens poster ici parce que je n'ai pas réussi à résoudre un soucis qui affecte mon mac depuis mon passage en 10.5.1. En effet :

- je ne peux plus lancer des applications ne peuvent plus se mettre à jour dont WoW : "Le fichier "/Applications/World of Warcraft/Background Downloader.app/Contents/MacOS/Blizzard Downloader" est en lecture seule et ne peut pas être mis à jour." alors qu'il a tous les droits "Lecture et écriture" !

- je ne peux plus sauver mes documents : CSSEdit ne peut plus sauver les fichiers CSS sur lesquels je travaille, il me propose sans cesse "Do you want to overwrite it anyway?" et "You do not have appropriate access privileges to save file “prismavilla.css” in folder “css”. To view or change access privileges, select the item in Finder and choose File > Get Info."

- à chaque suppression de fichiers, Finder me demande systématiquement le mot de passe de la session.


Ayant vu de rares réponses traitant de ce problème sur les forums mac :
- j'ai réparé les autorisations
- j'ai réinstallé la 10.5.1 via le site d'Apple

Je ne souhaiterai pas en arriver à formater mon mac !
Mac livré sous Leopard donc pas de problème de migration.
Problème uniquement apparu depuis la MAJ en 10.5.1 (avant je bossais très bien sous CSSEdit !).

Merci !

[steenux]

@darenzana:
Merci beaucoup pour cette explication détaillée

Je comprends mieux maintenant la différence entre le "@" et le "+", "Attributs étendus" et "ACL" qui sont deux choses complètements différentes.

[el Charlot]

Bonjour, je post ici mon problème, similaire, des ACL, sauf que c'est sur le dossier /private, et que je n'arrive pas a faire vos manips dessus, quelqu'un peut me donner un conseil ? merci

CODE

ACL trouvé mais non prétendu sur « private/var/root/Library/Preferences ».
ACL trouvé mais non prétendu sur « private/var/root/Library ».
ACL trouvé mais non prétendu sur « private/var/root ».

[darenzana]

Bonjour, je post ici mon problème, similaire, des ACL, sauf que c'est sur le dossier /private, et que je n'arrive pas a faire vos manips dessus, quelqu'un peut me donner un conseil ? merci

CODE

ACL trouvé mais non prétendu sur « private/var/root/Library/Preferences ».
ACL trouvé mais non prétendu sur « private/var/root/Library ».
ACL trouvé mais non prétendu sur « private/var/root ».

La manip que j'ai donnée à Joël Pierre face au même problème est : "on va dire que c'est pas grave non plus." Comment tu fais pour ne pas réussir à ne rien faire?
Tu as constaté des problèmes à l'utilisation?

Ce message a été modifié par darenzana - 10 Jan 2008, 20:50.

[Rigodon]

J'ai un problème étrange. J'ai effacé le groupe hérité de tiger qui a le même nom que l'utilisateur mais en installant perian je me suis aperçu qu'il avait créé des fichiers avec ce groupe comme propriétaire. Comment savoir si il en reste encore une trace?

[Rigodon]

Je viens de remarquer que l'utilisateur n'est pas dans le groupe staff. Quelle est la commande pour le mettre dans ce groupe ?

Apparemment ça a marché avec :
sudo dscl . create /groups/staff GroupMembership user

[darenzana]

Je viens de remarquer que l'utilisateur n'est pas dans le groupe staff. Quelle est la commande pour le mettre dans ce groupe ?

Apparemment ça a marché avec :
sudo dscl . create /groups/staff GroupMembership user

mmm pas bien ça, il fallait faire append, et non create. La tu as supprimé la liste des utilisateurs du groupe, en mettant juste le tien à la place. Tu devrais à nouveau ajouter l'ensemble des utilisateurs avec append.

J'ai un problème étrange. J'ai effacé le groupe hérité de tiger qui a le même nom que l'utilisateur mais en installant perian je me suis aperçu qu'il avait créé des fichiers avec ce groupe comme propriétaire. Comment savoir si il en reste encore une trace?

Tu avais bien modifié les propriétés de ton utilisateur pour le mettre dans le groupe staff, puis redémarré?
Tu as cherché avec 'find' si il n'existait plus aucun fichier avec le groupe en question?

Sinon, autre hypothèse, l'installateur de Perian est peut-être mal fichu et créé des fichiers avec le groupe d'id 501 de toutes façons...

[Rigodon]

Je crois que le problème vient de perian effectivement. Sinon pour create ce n'est pas grave car je n'ai qu'un utilisateur dans staff. J'ai trouvé append après.