5 votes

Impose de modifier le répertoire personnel de l'utilisateur racine : quels sont les inconvénients ?

J'ai un utilisateur principal, par exemple dave avec répertoire personnel /home/dave . Et il possède de nombreuses configurations pour les différents programmes qu'il peut exécuter, comme par exemple vim , bash etc. Lorsque je me connecte en tant que root toutes mes configurations ne sont pas utilisées puisque root a un répertoire personnel séparé : /root .

Je n'ai pas l'intention d'avoir d'autres utilisateurs sur ma machine. Est-ce que le fait de changer root dans le répertoire personnel de l'utilisateur dave a des inconvénients ?

6voto

Austin Hemmelgarn Points 357

Oui, beaucoup.

  • Tout ce que vous exécutez en tant que root et qui modifie la configuration ou l'état de $HOME mettra à jour le contenu de /home/dave , ce qui aura probablement pour conséquence que les fichiers modifiés appartiendront à root, ce qui les rendra impossibles à modifier sans être root (ce qui risque de casser certains programmes ( vim et la plupart des shells étant des exemples parfaits, l'historique des commandes finira par n'être utilisable que par root).
  • Toute personne ayant un accès en écriture à /home/dave peut théoriquement exécuter des commandes en tant que root. Gardez à l'esprit que de nombreux outils CLI ont des fichiers de démarrage dans $HOME qui obtiennent courir et pas seulement analysés, lorsque vous les démarrez. .bashrc y .vimrc sont des exemples triviaux, qui permettent tous deux à quiconque peut y écrire d'exécuter des commandes arbitraires avec les privilèges de l'utilisateur qui exécute la commande bash o vim d'une manière qui les utilise.
  • Quelques éléments qui pourraient être dans /root ne doit pas être lisible par d'autres utilisateurs pour des raisons de sécurité. Le premier exemple est celui des clés SSH ou GPG, mais il y en a d'autres. Fusionner /root avec un autre répertoire personnel, il est beaucoup plus difficile de s'assurer que ces secrets restent secrets. Notez que c'est la raison pour laquelle /root n'existe pas du tout, les anciens systèmes UNIX utilisaient simplement la fonction / en tant que répertoire personnel de root, ce qui a permis à d'autres utilisateurs d'obtenir de nombreuses informations.
  • Toute erreur de configuration dans les fichiers de configuration de l'application /home/dave qui rend impossible l'utilisation de la dave de se connecter, il sera également impossible à l'utilisateur root de se connecter. Cela signifie que cualquier les changements de configuration sont beaucoup plus risqués.

Notez que les deuxième et troisième points constituent des problèmes de sécurité potentiellement graves, même sur un système à utilisateur unique. Rappelez-vous toujours que toute attaque qui parvient à exécuter du code en tant qu'utilisateur peut faire tout ce que votre utilisateur peut faire.

Si votre objectif est simplement de partager la configuration sur l'ensemble du système, vous pouvez éviter tous les problèmes, sauf le dernier, en utilisant les fichiers de configuration sous /etc plutôt que dans les répertoires personnels. Il s'agit des valeurs par défaut de la configuration du système, de sorte que leur modification modifie la configuration pour tous les utilisateurs du système. Presque tous les outils interactifs CLI qui ont une forme de configuration qui n'est pas intrinsèquement spécifique à l'utilisateur ont des fichiers de configuration sous /etc .

1voto

Gogowitsch Points 125

Je jouerais la carte de la sécurité en ajoutant des redirections par commande.

Vous pouvez le faire de deux manières :

  • l'établissement de liens symboliques entre les fichiers de configuration un par un, par exemple pour vim : sudo ln -s /home/dave/.viminfo /root/.viminfo
  • en faisant précéder HOME=/home/dave à chaque commande. Vous pouvez créer un alias dans votre .bashrc afin que vous n'ayez pas à y penser :

    echo "alias vim='HOME=/home/dave vim'" | sudo tee -a /root/.bashrc

0voto

D. Ben Knoble Points 191

Si votre objectif est d'éditer des fichiers en tant que root il suffit d'utiliser sudoedit (Je crois que c'est équivalent à sudo -e ).

La commande ouvrira votre éditeur sur un fichier temporaire qui remplacera l'original en cas de sortie réussie. (La commande :cquit peut être utilisée pour faire échouer la sortie.)

En ce qui concerne le Shell, je suggérerais de le laisser à l'état brut. Il vous rappellera que vous ne voulez pas être connecté en tant que root pendant très longtemps. Si vous devez le faire, utilisez l'option /etc ou d'autres moyens de configurer spécifiquement la racine. Mais ne liez pas les fichiers.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X