Est-il possible d'utiliser l'utilisateur racine comme un utilisateur normal ?

Vous pouvez, mais c'est un risque majeur pour la sécurité et la stabilité. Cela permet à n'importe quelle application d'avoir un accès complet à votre ordinateur. Vous ne pouvez pas savoir ce qu'ils font avec cet accès. C'est inutile et vraiment dangereux.

Pour de plus amples informations sur ce sujet, voir

• Pourquoi est-ce mauvais de se connecter en tant que Root
• Pourquoi ne pas exécuter le programme en étant toujours connecté en tant que Root
• Pourquoi il n'est pas recommandé d'utiliser le Root login sous linux

Honnêtement, je suis d'accord qu'il y a beaucoup de risques associés à l'utilisation de la root utilisateur par défaut. Mais permettez-moi de les parcourir et de critiquer un peu certains arguments

• Se défendre contre les demandes : Pratiquement, le système de permission de *nix est pas assez forte (de loin) pour permettre l'exécution de programmes arbitraires. Un programme malveillant sur *nix est capable de faire suffisamment de choses maléfiques (comme voler vos identifiants bancaires) sans les autorisations Root. Il sera un peu plus difficile pour un programme non root que pour une root l'application (par exemple, au lieu d'installer directement un certificat racine et d'intercepter la connexion à la banque, vous devrez intervenir sur le navigateur, mais c'est tout à fait faisable et vous devrez probablement le faire de toute façon pour vous assurer que l'utilisateur ne remarque rien).
• Se défendre contre les erreurs des utilisateurs (comme l'exécution d'une mauvaise commande et la suppression de tous les fichiers système) : Absolument vrai, mais même si un non root Si l'utilisateur sauvegarde le système, tous les fichiers importants seront normalement déjà perdus (car les fichiers appartenant à l'utilisateur sont beaucoup plus susceptibles d'être uniques).
• Se défendre contre les bogues exploitables dans les applications que vous exécutez : Maintenant, c'est mieux comme ça. Par exemple, lorsque vous exploitez un serveur web où de nombreuses applications sont ouvertes sur l'extérieur et où tout bogue exploitable est facilement accessible. La même chose s'applique bien sûr même si vous êtes assis derrière un routeur et un pare-feu, bien que l'étendue du danger soit beaucoup moins importante. Une fois de plus, la question est de savoir dans quelle mesure le système de permission peut réellement défendre un système privé. Sans root L'accès à tous les fichiers privés reste possible et l'interception des données du réseau est également possible... les deux choses les plus importantes que vous pouvez souhaiter en tant qu'attaquant d'un système privé.
  • (Désormais, en plus du système de permission de fichiers *nix standard, Apple a également introduit un système de sandboxing des applications. Pour autant que je sache, ce système est toujours pleinement fonctionnel, même lorsque vous êtes connecté en tant que Root. Si toutefois il ne l'était pas, ce serait une rupture totale).

Quoi qu'il en soit, tout bien considéré, je ne pense pas que ce soit une idée aussi terrible que certains le prétendent. Je ne dis pas non plus que c'est une bonne idée, mais je pense que les gens surestiment l'utilité du modèle de permission du système de fichiers *nix pour vous protéger. Oui, il est incroyablement utile pour certaines choses (par exemple, les systèmes multi-utilisateurs, les serveurs multi-applications complexes, le maintien du système en fonctionnement quoi qu'il arrive (en fonctionnement, mais pas nécessairement utilisable), le verrouillage des fichiers importants (bien que vous feriez mieux de les crypter...), etc.

Dans les commentaires, j'ai trouvé une analogie qui semble tout à fait appropriée pour décrire la situation. En néerlandais, nous avons un mot pour le petit placard où l'on trouve tous les compteurs et la bascule pour l'alimentation principale en eau, etc. Courant comme le root compte utilisateur, c'est comme enlever la serrure de ce petit placard. Fait ironique : la plupart des gens n'ont pas de verrou dessus en premier lieu. Maintenant, tout comme avec le root utilisateur cela ne veut pas dire qu'il n'est pas utile de l'enfermer dans certains cas, par exemple dans les bureaux ou autres bâtiments semi-publics, il est souvent enfermé, mais dans les maisons normales, il est bien plus important d'avoir une serrure solide sur la porte d'entrée (ne pas installer des choses au hasard, un pare-feu, etc.) et de mettre toutes vos affaires importantes dans un coffre-fort (faire des sauvegardes, crypter les choses, etc.). Une serrure supplémentaire sur ce placard fera-t-elle mal ? Non, c'est peut-être une bonne idée de l'avoir en place au cas où, mais selon toute vraisemblance, elle sera inutile.

Courant comme le root l'utilisateur est rien comme de prendre toutes les serrures de votre maison et de garder sur vous en permanence toutes les affaires contenues dans le coffre, comme le prétend David Richerby. Votre passeport (identité) n'est en aucun cas protégé par le système de fichiers *nix, votre argent (compte bancaire) n'est en aucun cas protégé par le système de fichiers *nix, vos mots de passe importants ne sont pas protégés par le système de fichiers *nix. probablement non protégés par le système de fichiers *nix (si vous utilisez Safari, ils peuvent toutefois être partiellement protégés par le modèle de permission du système de fichiers *nix, mais sans les droits d'accès au système de fichiers *nix). root vous pouvez toujours ajouter une extension invisible à Safari et ensuite intercepter le mot de passe la prochaine fois que vous l'utiliserez), vos photos ne sont certainement pas protégées par le système de fichiers *nix et si vous utilisez le terminal, vous transportez déjà une tronçonneuse avec vous (selon le point 2 ci-dessus).

Vers 1990, je travaillais sur un projet avec un type nommé Tom. Nous utilisions un serveur SUN exécutant SunOS (un dérivé d'Unix, prédécesseur de Solaris). C'était à l'époque où les lecteurs de CD et les lecteurs flash n'existaient pas, donc si vous abîmiez le système d'exploitation sur votre disque dur, il n'y avait aucun moyen de le récupérer.

Tom avait l'habitude de se connecter en tant que Root. Je lui ai dit que c'était une mauvaise idée, mais il n'a pas écouté. Un jour, je l'ai entendu dire "Uh-oh". Il avait voulu taper quelque chose comme ça :

mv something* .

Malheureusement, il a omis le dernier point, et le shell a donc développé tous les noms de fichiers et de répertoires qui correspondaient à ce modèle. Ensuite, la commande mv a utilisé le nom final de la liste comme répertoire de destination, et y a déplacé tout le reste. Malheureusement, comme il se trouvait dans le répertoire Root, tout le système de fichiers a été déplacé dans l'un de ses sous-répertoires.

J'ai utilisé la flèche du haut pour revenir à la commande précédente et j'ai vu ce qui s'était passé. La première chose que j'ai dite alors était : "Ne vous déconnectez pas ! Ou tu ne pourras plus jamais te connecter."

Pas de problème, n'est-ce pas ? On pourrait juste tout remettre en place. Nous le pouvions, sauf que la commande mv n'était pas une des commandes intégrées du shell. Il s'agissait plutôt d'un programme exécutable, stocké dans l'un des fichiers qui avaient été déplacés. Heureusement, ls était une commande intégrée, donc après avoir utilisé ls pour confirmer où les commandes avaient été déplacées, j'ai pu trouver la commande mv, l'invoquer avec son nom de chemin complet, et remettre les choses où elles étaient supposées être.

Et puis je lui ai dit, "Tom, c'est pourquoi c'est une mauvaise idée de se connecter systématiquement en tant que Root."

En général, vous souhaitez que la propriété de vos fichiers personnels soit séparée de celle de l'utilisateur root. C'est pourquoi vous créez un compte pour vous-même en tant qu'administrateur. Sous OS X, la manière acceptée d'obtenir un accès au niveau racine est d'utiliser la fonction sudo à partir de l'application Terminal. Par exemple, si vous souhaitez voir le partitionnement de votre disque interne, la commande est la suivante

gpt -r show /dev/disk0

qui, si elle est saisie, donnera lieu au message d'erreur suivant.

gpt show: unable to open device '/dev/disk0': Permission denied

Pour utiliser cette commande, vous devez utiliser sudo comme indiqué ci-dessous.

sudo gpt -r show /dev/disk0

Si vous voulez devenir l'utilisateur racine pour éviter de saisir sudo vous pouvez simplement entrer sudo sh . Le site exit peut être utilisée pour quitter le statut d'utilisateur racine.

Si vous souhaitez exécuter une application en tant qu'utilisateur racine, vous pouvez le faire en utilisant l'application Terminal. Par exemple, si vous voulez lancer le Finder en tant qu'utilisateur root, entrez la commande suivante.

sudo /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder &

Pour éviter d'avoir deux applications Finder ouvertes en même temps, il est généralement préférable de quitter d'abord votre application Finder. Pour ce faire, utilisez la commande suivante dans le terminal.

osascript -e 'tell application "Finder" to quit'

Un mot d'avertissement : faire précéder une commande de sudo n'est pas la même chose que de devenir l'utilisateur racine. Par exemple, les commandes

sudo echo $USER
sudo echo $SUDO_USER

donnent les mêmes résultats que les commandes ci-dessous.

echo $USER
echo $SUDO_USER

Si vous devenez l'utilisateur racine (le superutilisateur), les mêmes commandes produisent un résultat différent. Ceci peut être vérifié en entrant les commandes ci-dessous.

sudo sh
echo $USER
echo $SUDO_USER
sudo echo $USER
sudo echo $SUDO_USER
exit