10.13 High Sierra Problème d’installation de High Sierra

[Yassblh]

Oui effectivement il est marqué Admin mais je ne sais pas pourquoi il m'affiche souvent erreur

 

[Membre supprimé 1060554]

Faisons 3 essais. Lance le Terminal.

- 1° passe d'abord la commande (copier-coller) :

ls /

• la commande liste les dossiers de 1er rang du volume démarré

=> est-ce que la commande passe bien automatiquement (elle ne requiert pas de privilèges) > en affichant une liste de dossiers ?

----------

- 2° passe la commande (copier-coller) :

sudo ls /

• tu passes la même commande > mais précédée de sudo (substitute_user_do) : opérer avec substitution d'identité (de root > le Super-Administrateur > si rien d'autre n'est spécifié)

• est-ce que tu vois s'afficher une demande de password ? --> tape alors en aveugle ton mot-de-passe de session - aucun caractère ne s'affichant à la frappe - et revalide

=> est-ce que la commande passe et affiche la même liste de dossiers que précédemment ?

----------

- 3° passe la commande (copier-coller) :

chmod 4755 /bin/chmod

• qui tente de fixer un suid_bit (substitute_user_id_bit : exécution automatique de chmod avec l'ID de root) > sur le fichier exécutable chmod (dont le propriétaire est root) > sans augmentation de privilèges via sudo

=> est-ce que tu obtiens en retour :

chmod: changing permissions of '/bin/chmod': Operation not permitted

 

[Awazleon]

Bonjour,

Je voulais juste remercier Macomaniac qui même si je ne lui ai rien demandé m'a permis de résoudre un problème d'installation/restauration avec un SSD et High Sierria.
Après avoir lu les quelques 27 pages de ce fil, plus d'autres sur ce même forum, j'ai pu régler mon problème. Cela faisait 4 jours que je patogeais dans la vase d'APFS.
Je ne sais pas qui se cache derrière ce pseudo mais chapeau bas, Monsieur. Je n'irais pas jusqu'à dire que APFS n'a plus de secret pour moi, ce serait faire preuve de fatuité, mais je me coucherai ce soir moins crétin et satisfait d'avoir mon vieil iMac qui tourne comme une horloge.

Bon week-end à tous

 

[Membre supprimé 1060554]

Awazleon

Content pour toi d'avoir pu t'aider sans agir directement (c'est le cas le plus reposant mais aussi le moins courant) !

 

[Yassblh]

La premiere commande est passé automatiquement .
la deuxième m'a demandé de taper mon password
et c'"est la troisième qui n'a pas marché je pense!

 

[Locke]

et c'"est la troisième qui n'a pas marché je pense!

Oui petit erreur de notre ami macomaniac, c'est plutôt chmod 755 donne au propriétaire tous les droits, aux membres du groupe et aux autres les droits de lecture et d'accès.

 

[Yassblh]

j'ai taper chmod 755 /bin/chmod, et elle a passé directement sans commentaire.

voila le retour

 

[Membre supprimé 1060554]

Donc tout est normal pour toi dans ton usage du terminal -->

• tu peux passer les commandes standards sans problème > tu peux passer les commandes requérant des privilèges (à cause des permissions des objets des commandes, par exemple) à condition d'utiliser sudo qui est validé > tu ne peux pas passer de commandes requérant des privilèges sans sudo

=> est-ce que les commandes que tu cherches à passer ne requièrent pas sudo au départ (parce que tu te heurtes à un problème de permissions) ?

----------

@ Locke

Hé non ! -->

- les permissions 755 root wheel everyone = les standards pour l'exécutable chmod (et de nombreux autres) : il ne servirait de rien de les réinscrire à l'identique > encore que cette réécriture à l'identique sans sudo --> aurait retourné le même déni de permission (l'expérience de Yassblh m'étonne à ce sujet)​

- les permissions 4755 root wheel everyone = des permissions atypiques et personnalisées > qui convertissent l'executable_bit x de l'utilisateur root de chmod => au suid_bit s. Ce qui permet (pour un détenteur ordinaire de compte dans l'OS) d'exécuter la commande appelant cet utilitaire sans sudo > car le suid_bit assure une exécution automatique avec l'identité de root. Le suid_bit est donc une espèce de sudo à validité permanente fixé sur un exéctuable et ne requérant aucune authentification à l'usage.​

 

[Yassblh]

Dans ce que je tape la commande avec ou sans le chiffre 4 ?

 

[Membre supprimé 1060554]

Il est normal que tu n'aies pas pu fixer le suid_bit sans sudo : il est donc normal encore que tu aies eu un déni de permissions. C'était le but de ma 3è commande dans les petits exercices ci-dessus : vérifier si ton fonctionnement d'opérateur dans le terminal était comme il doit être. Eh bien ! --> c'est le cas.

----------

Quelles sont donc les commandes que tu n'arrives pas à passer dans le Terminal (ton problème de départ) ? - n'est-ce que pas des commandes requérant sudo > que tu tentes de passer sans sudo ?

 

[Locke]

Hé non ! -->

- les permissions 755 root wheel everyone = les standards pour l'exécutable chmod (et de nombreux autres) : il ne servirait de rien de les réinscrire à l'identique > encore que cette réécriture à l'identique sans sudo --> aurait retourné le même déni de permission (l'expérience de Yassblh m'étonne à ce sujet)
- les permissions 4755 root wheel everyone = des permissions atypiques et personnalisées > qui convertissent l'executable_bit x de l'utilisateur root de chmod => au suid_bit s. Ce qui permet (pour un détenteur ordinaire de compte dans l'OS) d'exécuter la commande appelant cet utilitaire sans sudo > car le suid_bit assure une exécution automatique avec l'identité de root. Le suid_bit est donc une espèce de sudo à validité permanente fixé sur un exéctuable et ne requérant aucune authentification à l'usage.

Exact, je n'avais pas pensé aux droits d'accès étendus.

 

[Yassblh]

tout a fait, se sont des commandes sans sudo

 

[Membre supprimé 1060554]

Essaie de les passer avec sudo. Tu n'es peut-être pas le proprétaire des objets sur lesquels portent les commandes...

 

[Yassblh]

Ok, ça sera fait je vous remercie et vous souhaite un bon week-end.