web-dev-qa-db-fra.com

Comment Sudo gère-t-il $ HOME différemment depuis 19.10?

Dans les versions d'Ubuntu antérieures à Ubuntu 19.10 Eoan Ermine, lorsque j'exécute une commande avec Sudo, cette commande reçoit mon répertoire personnel dans le $HOME variable d'environnement. C'est le comportement que j'attendais depuis longtemps et a mis en garde d'autres personnes . Si je veux que Sudo réinitialise le $HOME variable d'environnement, pour qu'il fasse référence au répertoire personnel de l'utilisateur cible au lieu du mien, je dois passer le -H option (ou -i, bien que cela fasse plus).

ek@Kip:~$ lsb_release -d
Description:    Ubuntu 18.04.3 LTS
ek@Kip:~$ Sudo printenv HOME  # Shows ek's home, not root's.
/home/ek
ek@Kip:~$ Sudo -u as printenv HOME  # Shows ek's home, not as's.
/home/ek
ek@Kip:~$ Sudo -H printenv HOME  # Shows root's home.
/root
ek@Kip:~$ Sudo -Hu as printenv HOME  # Shows as's home.
/home/as

Lors de ma première mise à niveau vers Ubuntu 19.10, j'ai été surpris de découvrir que Sudo semble réinitialiser $HOME peu importe quoi ! Je continue à observer cela maintenant que 19.10 est sorti et j'ai installé des mises à jour - à la fois sur les systèmes nouvellement installés et celui que j'ai mis à niveau vers 19.10.

ek@Cord:~$ lsb_release -d
Description:    Ubuntu 19.10
ek@Cord:~$ Sudo printenv HOME  # Shows root's home, even without -H or -i.
/root
ek@Cord:~$ Sudo -u as printenv HOME  # Shows as's home, even without -H or -i.
/home/as
ek@Cord:~$ Sudo -H printenv HOME  # Also shows root's home.
/root
ek@Cord:~$ Sudo -Hu as printenv HOME  # Also shows as's home.
/home/as

J'ai pensé que cela pourrait être dû à fichiers de configuration mis à jour . Mais j'ai vérifié, et always_set_home n'apparaît dans aucune ligne Defaults dans mon 19.10 /etc/sudoers fichier.

Ce qui fait que Sudo traite $HOME différemment à partir de 19.10, et pourquoi cette modification a-t-elle été apportée? Est-ce que cela permet d'utiliser en toute sécurité Sudo dans les cas où j'aurais précédemment utilisé Sudo -H?

sudohome-directoryenvironment-variables19.10history-of-ubuntu
66
Eliah Kagan

Pendant des années, Ubuntu a livré une version corrigée de Sudo qui préserve $HOME par défaut . Outre Ubuntu et ses dérivés, très peu d'autres systèmes d'exploitation (peut-être aucun autre) font cela . Il a été décidé que cela causait plus de problèmes qu'il n'en résout , et à partir d'Ubuntu 19.10 , $HOME n'est plus l'un des quelques variables d'environnement Sudo préserve.

En termes de qu'est-ce que le changement et comment il affecte les utilisateurs, les points clés sont:

  • Depuis Ubuntu 19.10, Sudo command fait ce que fait Sudo -H command dans les versions précédentes. It peut en effet être utilisé dans des cas qui auraient précédemment conseillé à Sudo -H, y compris d'exécuter des applications GUI en tant que root ou autre utilisateur . Exécuter des programmes graphiques en tant que root reste controversé . Mais en 19.10, vous pouvez exécuter Sudo gedit avec exactement le même effet que Sudo -H gedit. Dans 19.10, des commandes comme Sudo gedit ne créent plus des problèmes de propriété de fichier ennuyeux dans votre répertoire personnel.
  • Cela s'applique même sur les systèmes mis à niveau vers 19.10 à partir d'une version antérieure , même lorsque la mise à niveau ne modifie pas votre fichier /etc/sudoers. Le changement se trouve dans le code source du programme Sudo lui-même, pas dans ses fichiers de configuration par défaut. (Il peut être remplacé dans un fichier sudoers, mais vous savez probablement si vous avez fait cela.)
  • Il ne s'applique pas - et ne s'appliquera pas - aux versions antérieures à 19.10. Avant 19.10, Sudo préserve $HOME par défaut, et les futures mises à jour de Sudo ne changeront pas cela. Par exemple, 18.04 LTS aura toujours l'ancien comportement, même dans les futures versions ponctuelles.
  • Sudo -H command fonctionne toujours bien. Si vous avez l'habitude de l'utiliser, pas de problème. Vous n'avez tout simplement pas à le faire, sur un système 19.10.
  • La plupart des commandes que vous exécutez avec Sudo ne se comporteront pas différemment. Dans l'immense majorité des situations où vous n'auriez pas passé -H, vous pourriez avoir. Certains utilisateurs s'appuient sur ou préfèrent autrement l'ancien comportement de conservation de $HOME. Mais cela a souvent eu des effets inattendus . Donc, si vous vous en remettiez à cela, vous pourriez toujours ne pas vouloir remplacer la modification dans un fichier sudoers.

Voir aussi Réponse de WinEunuuchs2Unix à Pourquoi les utilisateurs ne devraient-ils jamais utiliser Sudo normal pour démarrer des applications graphiques?

Pourquoi le changement

Comme le changelog le met (sous "Sudo (1.8.27-1ubuntu2) eoan"):

Cela restaure la gestion Sudo de $ HOME à ce que tout le monde fait

"Tout le monde" fait référence au projet en amontSudo ( hébergé ici ) et apparemment tous tous les autres systèmes d'exploitation qui contiennent Sudo, à l'exception de ceux qui dérivent d'Ubuntu.

Mais il y a plus. Ceci est également considéré comme corrigeant un bogue de sécurité, comme décrit dans le correctif Ubuntu pour ajouter HOME à env_keep rend les commandes personnalisées vulnérables par défaut . L'histoire a été résumée de manière concise dans ce commentaire là par Steve Langasek (dont vous avez peut-être entendu parler de ), que j'ai citation complète:

Cette modification a été initialement introduite en réponse à bug # 760140 .

Le changement en amont dans Sudo n'a jamais été accompagné d'un CVE, et le changement de comportement n'a jamais été appliqué aux versions précédentes d'Ubuntu, donc il ne semblait pas sensible à la sécurité à l'époque.

Je ne suis pas opposé à ce que cela change pour se comporter comme Simon le décrit, mais je m'en remets à l'équipe de sécurité ici.

Todd C. Miller, , qui gère le projet Sudo en amont (très activement et depuis de nombreuses années maintenant), a également été invité à fournir des commentaires sur la question. Il a expliqué la raisonSudo réinitialise (c'est-à-dire, ne conserve pas) $HOME:

Le jeu 16 mai 2019 07:48:40 -0400, Dan Streetman a écrit:

J'ai cc'ed Sudo-utilisateurs, donc la question à la liste amont Sudo peut être résumée comme suit:
Quelle serait la probabilité que Sudo en amont ajoute HOME à env_keep par défaut?

Extrêmement improbable. Avant Sudo 1.7.4, les variables d'environnement HOME et MAIL étaient conservées par défaut dans l'environnement. Cela peut conduire à des programmes utilisant des fichiers de configuration dans le répertoire de base de l'utilisateur d'origine, ce qui a des implications sur la sécurité, donc la valeur par défaut a été modifiée dans 1.7.4.

Autrefois, Sudo ne faisait guère plus que changer le UID. De nos jours, Sudo essaie d'exécuter la commande dans un environnement qui correspond étroitement à ce que vous obtiendriez en vous connectant en tant qu'utilisateur. Cela s'est avéré plus sûr car il correspond plus étroitement aux hypothèses émises par d'autres programmes.

Nous le demandons car Ubuntu porte un patch qui ajoute HOME à env_keep, contrairement à l'amont par défaut, ou à tout autre Linux/Unix. Nous envisageons de supprimer ce correctif, pour correspondre aux valeurs par défaut en amont, de pas , y compris HOME dans env_keep.

J'appuierais cela. Je pense que la réinitialisation de HOME est la valeur par défaut la plus sûre.

- todd

(J'ai modifié la mise en forme de le message d'origine pour l'afficher correctement sur ce support.)

Depuis le 19.10, le downstreamSudo dans Ubuntu se comporte comme le Sudo amont (et Sudo dans d'autres systèmes d'exploitation, y compris Debian) se comporte depuis de nombreuses années. Pour des informations plus détaillées sur l'historique de ce changement et les développements qui l'ont précédé, y compris de nombreux liens pour une lecture plus approfondie, consultez la section "Sudo et $HOME: Les 20 dernières années" ci-dessous.

Hein? a.k.a. Pourquoi est-ce (parfois) important ce que fait Sudo avec $HOME

Les programmes que vous exécutez qui ont besoin de l'emplacement de votre répertoire home examinent souvent la valeur de la variable d'environnement $HOME. Un cas important est lorsqu'un programme essaie de stocker et d'accéder à fichiers de configuration dans le répertoire personnel de l'utilisateur qui l'exécute. Les programmes utilisent généralement la valeur de $HOME. Parfois, lorsque vous exécutez un programme en tant qu'utilisateur substitut - par exemple, en tant que compte root - il est intéressant que ce programme utilise vos paramètres . Mais cela peut aussi devenir compliqué, de deux manières:

  1. Habituellement, lorsque vous exécutez une commande en tant qu'autre utilisateur, vous souhaitez qu'elle fonctionne principalement de la même manière que si cet utilisateur l'avait exécutée. Mais s'il s'agit d'une commande dont le comportement peut être radicalement modifié par le fait que vous l'avez exécutée - ce qui se produit si son comportement est fortement personnalisé par les données lues à partir des fichiers trouvés dans le répertoire nommé dans $HOME-- alors cet objectif n'est pas atteint.

    Lorsque vous êtes autorisé à effectuer toute action que vous choisissez en tant qu'utilisateur, y compris root (qui, dans Ubuntu, est conféré par l'appartenance au groupe Sudo), le problème est principalement un accident. Cependant, si vous êtes un utilisateur limité et que vous avez été autorisé à exécuter uniquement des commandes spécifiques avec Sudo, le fait de pouvoir manipuler ce que font ces commandes a de sérieuses implications en termes de sécurité. Le rapport de bogue qui a conduit au changement en 19.10 était spécifiquement motivé par ce problème (et inclut un exemple convaincant de celui-ci ).

  2. Si vous exécutez une commande en tant qu'un autre utilisateur et que la commande modifie sa configuration dans le répertoire nommé dans $HOME, une tentative est effectuée pour écrire les modifications dans les fichiers à cet emplacement. Lorsque l'utilisateur substitut n'est pas root, comme dans Sudo -u usernamecommand, cela échoue généralement et génère des messages d'erreur, ce qui est légèrement ennuyeux mais pas grave.

    Mais dans le cas commun où l'utilisateur substitut est root, comme dans Sudo command, cela réussit, mais si des nouveaux fichiers sont créés, ils appartiennent à root et votre compte utilisateur n'a plus un accès complet à tous ses propres fichiers de configuration. Cela peut être corrigé par chown ing les fichiers en arrière, donc le problème est plus grave dans le cas des applications graphiques, dont la complexité peut faire donc plus de fichiers, dans plus d'endroits, sont impliqués (et où il a été signalé parfois rendre la connexion difficile , bien que généralement le problème est moins grave que que ).

Ce qui a changé et pourquoi tous les systèmes 19.10 ont changé

Une courte liste blanche de variables d'environnement qui ne sont pas réinitialisées par défaut est codée en dur dans Sudo lui-même. Dans les versions d'Ubuntu antérieures à 19.10, un correctif spécifique à Ubuntu ajoute $HOME à cette liste blanche. Il est compilé dans un fichier binaire utilisé par Sudo, donc la mise à niveau vers une version de Sudo qui n'a pas le patch le supprime de la liste blanche.

Le patch a été supprimé en 19.10 . La mise à niveau vers 19.10 ou supérieur appliquera donc toujours le changement, même si aucun fichier de configuration associé à Sudo n'est modifié.

Il est toujours possible de configurer n'importe quelle version de Sudo pour conserver $HOME (voir ci-dessous). Dans le cas extrêmement inhabituel où vous l'avez fait avant 19.10 - alors qu'une telle configuration n'aurait fait aucune différence - et conservé cette configuration pendant une mise à niveau, $HOME serait toujours conservé. Mais vous vous souviendrez probablement d'avoir fait cette chose étrange.

Si votre mise à niveau vers 19.10 (ou version ultérieure) a échoué et vous a donné un système uniquement partiellement mis à niveau avec une version de Sudo antérieure à 19.10, alors Sudo sur ce système conserve toujours $HOME par défaut. C'est presque le seul cas où Sudo conserverait $HOME en 19.10 (ou version ultérieure) sans que vous le sachiez - bien que vous ayez toujours été informé, pendant la mise à niveau de la version, que tous les packages ne pouvaient pas être mis à niveau.

La façon la plus simple de voir directement que le correctif a disparu dans le code source de Sudo dans Ubuntu 19.10 est de comparer https://git.launchpad.net/ubuntu/+source/Sudo/tree/debian/patches? h = ubuntu/disco-security to https://git.launchpad.net/ubuntu/+source/Sudo/tree/debian/patches?h=ubuntu/eoan .

Néanmoins, si vous ne savez pas comment votre système est configuré, vous pouvez exécuter Sudo printenv HOME pour le savoir.

Réinitialisation de $HOME dans Ubuntu 19.04 et versions antérieures

Bien que les mises à jour de Sudo dans Ubuntu 19.04 et versions antérieures puissent inclure des modifications de la documentation pour expliquer la situation, la façon dont Sudo traite $HOME dans ces versions n'a pas été et ne sera pas modifiée par les mises à jour. La plupart des utilisateurs ne voudront pas se soucier de modifier manuellement le fonctionnement de Sudo sur les systèmes où ils l'utilisent déjà sans problème. Cependant, si vous le souhaitez, vous pouvez faire Sudo réinitialiser $HOME sur ces systèmes, même sans les mettre à niveau.

Chaque fois que vous exécutez Sudo, vous pouvez utiliser l'option -H/--set-home pour réinitialiser $HOME:

Sudo -H command

Ou vous pouvez utiliser -i. Cela fait plus que réinitialiser $HOME. Sudo -i command se comporte comme si vous vous êtes connecté en tant que root, avez exécuté command et vous êtes déconnecté; Sudo -i se comporte comme si vous vous étiez connecté en tant que root et vous place dans un shell racine interactif. Cela diffère de Sudo -s, qui démarre un shell interactif qui n'est pas un shell de connexion. Avant Ubuntu 19.10, Sudo -s préserve $HOME; autrement dit, quelle que soit la version, l'option -s ne comporte aucun comportement qui affecte la façon dont $HOME est traité. Il est utile d'utiliser -H et -s ensemble. Vous pouvez également utiliser -H, -i et -s avec -u user pour devenir user plutôt que root. Enfin, l'utilisation de Sudo via les interfaces graphiques gksu ou gksudo (toujours disponible dans 16.04 LTS, mais vous devrez peut-être installer le package gksu) réinitialise $HOME.

Si vous souhaitez reconfigurer Sudo afin qu'il remette toujours à zéro $HOME, vous pouvez activer l'option always_set_home dans un fichier sudoers:

Defaults    always_set_home

Vous ajouteriez cette ligne à /etc/sudoers ou, mieux, à un nouveau fichier dans /etc/sudoers.d/. Dans les deux cas, vous devez utiliser visudo pour modifier le fichier, afin de bénéficier de la vérification de la syntaxe. (Une erreur de syntaxe dans n'importe quel fichier sudoers fait que Sudo refuse de fonctionner du tout. C'est un problème, bien que cela puisse être corrigé .)

Par exemple, sur certains de mes systèmes antérieurs à 19.10, j'ai créé et modifié /etc/sudoers.d/always_set_home en exécutant:

Sudo visudo -f /etc/sudoers.d/always_set_home

Dans le fichier, j'ai écrit la ligne Defaults ci-dessus. Le nom de fichier n'a pas besoin d'être always_set_home - il peut être ce que vous voulez, tant qu'il ne contient aucun caractère . ou ~. Le mot sur la ligne Defaults fait , bien sûr, doit être exactement always_set_home.

(Une raison de préférer créer un nouveau fichier dans /etc/sudoers.d/ plutôt que de modifier le fichier /etc/sudoers existant est que, si jamais une mise à jour future modifie le fichier /etc/sudoers par défaut, vous pouvez accepter le nouveau fichier sans perdre vos personnalisations. Une autre raison est qu'il est immédiatement clair que vous avez modifié la configuration et où vos modifications peuvent être trouvées.)

Si vous faites cela et souhaitez exécuter une commande Sudo individuelle qui préserve $HOME, vous pouvez le faire de la même manière que vous le feriez en 19.10 (voir ci-dessous).

Préservation de $HOME dans Ubuntu 19.10 et versions ultérieures

La façon dont Sudo traite $HOME a été modifiée pour une raison. (Voir les sections ci-dessus, ainsi que la section d'historique détaillé ci-dessous.) Mais si vous voulez vraiment que Sudo continue de conserver $HOME, même en 19.10 et versions ultérieures, vous pouvez configurer ce comportement dans un fichier sudoers.

Chaque fois que vous exécutez Sudo, vous pouvez lui dire de conserver $HOME avec --preserve-env=HOME:

Sudo --preserve-env=HOME command

Il s'agit de la forme de --preserve-env qui est documentée comme --preserve-env=list dans la page de manuel Sudo . Il est également possible d'utiliser --preserve-env sans opérande de liste, qui est identique à -E; qui préserve toutes les variables d'environnement . Mais il y a rarement une bonne raison de le faire, surtout si votre objectif est simplement de préserver $HOME. Si vous n'aimez pas taper --preserve-env=HOME, vous pouvez définir un alias ou une fonction Shell ou écrire un script qui vous permet d'exécuter une commande plus courte pour le faire. Il serait encore mieux de conserver rarement $HOME (voir la section ci-dessous sur les alternatives à cela).

Plus généralement, vous pouvez faire en sorte que Sudo préserve une variable d'environnement particulière varname avec --preserve-env=varname. (Vous pouvez également voir du code qui préserve efficacement $HOME en le définissant explicitement dans la commande Sudo s'exécute, comme avec Sudo HOME="$HOME" command. Cela fonctionne également. Il est assez différent de HOME="$HOME" Sudo command, ce qui n'empêcherait pas Sudo de réinitialiser $HOME.)

Ou si vous voulez vraiment faire en sorte que Sudo conserve toujours $HOME, vous pouvez le faire en ajoutant $HOME à env_keep dans un fichier sudoers:

Defaults    env_keep += "HOME"

Cela peut aller dans /etc/sudoers ou un fichier dans /etc/sudoers.d/. Bien que je souligne que je ne recommande pas du tout cela, si vous décidez de le faire, je vous suggère de créer et de modifier /etc/sudoers.d/keep-home (appelez le fichier comme vous le souhaitez, tant que le nom ne contient pas . ou ~) par fonctionnement:

Sudo visudo -f /etc/sudoers.d/keep-home

Ensuite, vous pouvez mettre cette ligne Defaults dans le fichier.

La raison d'utiliser += au lieu de simplement = est qu'il existe une poignée d'autres variables d'environnement, codées en dur dans Sudo lui-même, qui sont préservées par défaut et que vous souhaitez probablement conserver. Si vous avez utilisé =, alors seules les variables d'environnement que vous avez répertoriées explicitement dans le fichier seront conservées. Dans ce cas, ce serait juste $HOME. Plus d'informations sur la grammaire des fichiers sudoers sont disponibles dans sudoers (5) .

Quant à savoir pourquoi je suggère de créer un fichier dans /etc/sudoers.d/ au lieu de modifier /etc/sudoers-- et pourquoi vous devriez certainement utiliser visudo dans les deux cas - voir mes commentaires dans la section "Réinitialisation de $HOME dans Ubuntu 19.04 et versions antérieures" ci-dessus.

Alternatives à la conservation de $HOME

La plupart du temps, vous utilisez Sudo, la meilleure alternative à la conservation de $HOME est de ne rien faire. La plupart des commandes Sudo ont le même effet (et certaines fonctionnent légèrement mieux) sans $HOME préservé. Cependant, je connais deux cas d'utilisation courants pour la conservation de $HOME.

Utilisation de la configuration et/ou des plugins de votre éditeur de texte pour modifier les fichiers appartenant à root ou à un autre utilisateur. sudoedit, ou de manière équivalente Sudo -e, est une alternative idéale pour cela. Il exécute l'éditeur comme vous , vous modifiez une copie temporaire du fichier et le fichier est mis à jour lorsque vous quittez l'éditeur. Étant donné que l'éditeur s'exécute en tant que vous, il utilise automatiquement votre configuration et vos plugins, sans risque d'échouer de manière opaque et inattendue avec des autorisations refusées ou de rendre les fichiers de votre répertoire personnel inaccessibles. Pour modifier file:

sudoedit file

Pour modifier file aveceditorau lieu de l'éditeur par défaut:

Sudo_EDITOR=editor sudoedit file

Par exemple, Sudo_EDITOR=vim sudoedit /etc/apt/sources.list édite /etc/apt/sources.list avec vim.

Pour décider de l'éditeur à utiliser, sudoedit consulte la variable d'environnement$Sudo_EDITOR; si ce n'est pas le cas, il consulte $VISUAL; si ce n'est pas le cas, il consulte $EDITOR; si ce n'est pas le cas, il essaie les commandes de l'éditeur à partir d'une liste codée en dur, ce qui signifie en pratique dans Ubuntu qu'il utilise editor. En règle générale, cela se résout en /usr/bin/editor, qui est un lien symbolique. Si vous souhaitez modifier l'éditeur par défaut à l'échelle du système , vous pouvez modifier ce vers quoi /usr/bin/editor pointe en exécutant Sudo update-alternatives --config editor. Vous pouvez également définir l'une de ces trois variables d'environnement, ce qui est un bon moyen de modifier les modifications de sudoedit pour un seul utilisateur.

Rendre les programmes que vous exécutez uniquement en tant que root utilise des fichiers de configuration spécifiques. Si un programme que vous exécutez en tant que root regarde dans $HOME pour sa configuration, alors vous pouvez simplement mettre cette configuration dans (ou déplacer cette configuration vers) le répertoire personnel de root, /root.

Réinitialisation de $HOME lorsque vous ne savez pas quelle version vous utilisez

Vous pouvez parfois écrire une commande et ne pas savoir sur quelle version d'Ubuntu (ou sur quels systèmes d'exploitation en dehors d'Ubuntu) elle s'exécutera. Par exemple, vous pouvez écrire un script que vous exécuterez sur plusieurs machines.

Sudo continue d'accepter l'option -H, avec le même effet qu'elle a toujours eu. Il se trouve que, à partir du 19.10, Sudo sans -H fait la même chose (sauf si vous l'avez configuré pour faire autrement) que Sudo -H.

Pour écrire des commandes portables Sudo qui réinitialisent $HOME, vous pouvez continuer à utiliser:

Sudo -H command

(De même que précédemment, si toutes les actions effectuées dans votre script doivent être effectuées en tant que root, il est probablement préférable de ne pas utiliser Sudo dans votre script et d'exécuter simplement le script en tant que root avec Sudo.)

Sudo et $HOME: Les 20 dernières années

Vers le début du siècle , le projet en amontSudo a introduit l'option env_reset, qui permet à Sudo de réinitialiser la plupart des variables d'environnement. Cette option est activée sauf si elle est désactivée explicitement dans un fichier sudoers. (Il est possible de l'activer explicitement, ce que fait Defaults env_reset dans le fichier Debian et Ubuntu /etc/sudoers, mais ce n'est pas vraiment nécessaire.) Avant Sudo avait env_reset, toutes les variables d'environnement étaient conservées inchangées. Avec env_reset, seule une poignée de variables ont été préservées. Cela comprenait $HOME.

En juillet 2010 , $HOME a été supprimé de cette petite liste blanche et n'est donc plus conservé par défaut.

En septembre 2010 , un rapport de bogue concernant la documentation de cela dans le paquet Sudo dans Debian a été déposé. Pour autant que je sache, il n'y a pas eu de controverse ou d'objection au changement lui-même, de la part des développeurs Debian. (Mais voir ci-dessous.)

En février 2011 , le changement était allé plus loin downstream de Debian à Ubuntu et les développeurs d'Ubuntu ont discuté de l'opportunité ou non.

En avril 2011 , la modification a été signalée comme un bug, faisant référence à cette discussion. (Un comportement résultant du changement avait été signalé comme un bug la veille.) Au moins à l'époque, c'était considéré comme un regression ("le responsable Debian a déjà essayé de résoudre ce problème une fois mais il semble que le correctif était incomplet"). Je n'ai pas trouvé un tel rapport de bogue Debian, mais cela ne signifie pas qu'il n'y en avait pas; en outre, un changement aurait pu être fait sans celui-ci. Je soupçonne cependant que cela peut avoir été une référence erronée à ce bogue de documentation .

Le lendemain , la version de développement d'Ubuntu a été mise à jour avec un correctif en aval, uniquement Ubuntu, pour ajouter à nouveau $HOME à la liste des variables d'environnement Sudo conservées par défaut. Je crois que cela a été fait rapidement afin d'en faire la sortie d'Ubuntu 11.04. L'effet était que Sudo dans 11.04, comme dans les versions précédentes d'Ubuntu, préservait $HOME par défaut.

En novembre 2011 , un bogue a été signalé sur la façon dont la documentation de Sudo dans Ubuntu indiquait que $HOME avait été réinitialisé. Autrement dit, la page de manuel dans Ubuntu décrit correctement le comportement de Sudo en amont, mais pas le comportement corrigé dans Ubuntu.

En septembre 2014 , un bogue a été signalé signalant certains des problèmes liés à la conservation par défaut de Sudo$HOME et faisant valoir que le problème lié à l'exécution de programmes graphiques avec Sudo normal n'est pas qu'il est intrinsèquement dangereux ( souvent cité dans cette page wiki ) mais que la gestion inhabituelle de Sudo de $HOME dans Ubuntu le rend dangereux et doit être considéré comme un bug. Il semble qu'il y ait eu un intérêt significatif pour ce rapport de bogue, y compris de la part des développeurs Ubuntu, même s'il faudra un certain temps avant qu'il ne soit corrigé.

En mars 2016 , le bogue qui deviendrait plus tard la principale référence pour les problèmes avec Sudo préservant $HOME a été signalé. Initialement, ce rapport de bogue se concentrait spécifiquement sur le problème de sécurité que les utilisateurs qui ne sont pas administrateurs (c'est-à-dire, ne peuvent pas exécuter de commandes arbitraires en tant que root), mais qui ont été autorisés à exécuter des commandes spécifiques avec Sudo, peut altérer de manière malveillante le comportement de certains programmes et, dans certains cas, obtenir le contrôle total du système. Il a recommandé une modification étroite qui tenterait de résoudre ce cas spécifiquement, tout en conservant $HOME préservé lorsque les membres du groupe Sudo exécutent des commandes en tant que root ou autre utilisateur.

En avril 2019 , un bogue a été signalé s'opposant au comportement de Sudo préservant $HOME par défaut, même lorsque Sudo -s est utilisé.

Plus tard ce mois-ci , la discussion a repris sur le bogue mars 2016 , vers la résolution possible de la suppression du correctif spécifique à Ubuntu. Cela a élargi la portée de ce rapport de bogue au-delà de la vulnérabilité de sécurité spécifique qu'il a décrite. L'objectif de faire en sorte que Sudo dans Ubuntu traite $HOME de la même manière en amont Sudo (et Sudo dans d'autres systèmes d'exploitation) le traite, à partir d'Ubuntu 19.10, a été articulé.

En mai 2019 , un bug a été signalé sur la façon dont les programmes (y compris les programmes non graphiques) qui utilisent launchpadlib rencontraient des problèmes de propriété du fichier de configuration car Sudo préserve $HOME.

Une semaine plus tard , une autre discussion sur la liste de diffusion sur "comment Sudo gère $ HOME" a eu lieu (voir aussi cette page d'archives ), présentant une gamme de vues sur comment Sudo doit traiter $HOME. Une préférence qui n'était pas controversée était que si un changement devait être fait, il ne devrait être que vers 19.10 et plus tard , et ne pas être fait dans aucun mises à jour pour les versions précédentes . La question s'est posée pour savoir si en amont Sudo continuerait de réinitialiser $HOME dans les futures versions.

Le responsable amont Sudo , lorsque consulté à ce sujet , a clairement indiqué que aucun changement en amont n'est prévu et a soutenu la vue que la version en aval de Sudo dans Ubuntu devrait également réinitialiser $HOME par défaut. Ce message, publié à l'origine sur la liste de diffusion des utilisateurs Sudo , était cité dans un commentaire sur le rapport de bogue de mars 2016 .

En juin 2019 , les développeurs d'Ubuntu ont prévu de supprimer le correctif qui fait que Sudo dans Ubuntu conserve $HOME.

Environ une semaine plus tard , la modification a été effectuée dans les référentiels d'Ubuntu. Cette modification s'applique à partir de 19.10. La seule modification qui sera apportée à Sudo dans les versions antérieures est de mettre à jour la documentation afin qu'elle décrive clairement et correctement le comportement de Sudo dans ces versions.

Remerciements

88
Eliah Kagan