Pendant des années, Ubuntu a a envoyé 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é a décidé que cela causait plus de problèmes que cela n'en résolvait. y à partir d'Ubuntu 19.10 , $HOME n'est plus l'une des rares variables d'environnement sudo conserves.
En termes de ce que le changement est et comment il affecte les utilisateurs, les points clés sont les suivants :
-
A partir d'Ubuntu 19.10,
sudo _command_ fait ce qui suit sudo -H _command_ fait dans les versions précédentes. Il peut en effet être utilisé dans des cas qui auraient auparavant conseillé sudo -H dont pour exécuter des applications GUI en tant que root ou un autre utilisateur . Exécution de programmes graphiques en tant que root dans tous les cas reste controversé . Mais en 19.10, vous pouvez exécuter sudo gedit avec exactement le même effet que sudo -H gedit . En 19.10, des commandes comme sudo gedit ne créent plus problèmes ennuyeux de propriété de fichiers dans votre répertoire personnel.
-
Ceci s'applique même sur les systèmes mis à niveau vers 19.10 à partir d'une version antérieure même si la mise à niveau ne modifie pas votre situation.
/etc/sudoers fichier. Le changement se trouve dans le code source de la sudo du programme lui-même, et non dans ses fichiers de configuration par défaut. (Elle peut être remplacée dans un fichier sudoers mais vous le sauriez probablement si vous le faisiez).
-
Il ne s'applique pas - et ne s'appliquera pas - aux versions antérieures à 19.10. Avant 19.10,
sudo conserve $HOME par défaut, et les futures mises à jour de sudo ne changera pas ça. Par exemple, la version 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. Mais vous n'êtes pas obligé de le faire sur un système 19.10.
-
Le plus les commandes que vous exécutez avec
sudo ne se comportera pas différemment. Dans l'écrasante majorité des situations où vous voudriez pas sont passés -H vous pourrait ont. Certains utilisateurs s'appuient sur ou préfèrent l'ancien comportement de préserver $HOME . Mais cela ont souvent eu des effets inattendus . Donc si vous comptez sur ça, vous pourriez toujours pas vous voulez remplacer la modification dans un sudoers fichier.
Voir aussi La réponse de WinEunuuchs2Unix a Pourquoi les utilisateurs ne devraient jamais utiliser le sudo normal pour démarrer des applications graphiques ?
Pourquoi ce changement ?
Comme le journal des modifications le met (sous "sudo (1.8.27-1ubuntu2) eoan") :
Cela rétablit la gestion sudo de $HOME comme tout le monde le fait.
"Tout le monde" fait référence à la en amont sudo projet ( hébergé ici ) et aussi apparemment 何れも d'autres systèmes d'exploitation qui contiennent sudo sauf ceux qui dérivent d'Ubuntu.
Il y a plus que ça, cependant. Ceci est également considéré comme la correction d'un bogue de sécurité, comme décrit dans Le patch 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à por Steve Langasek (qui vous avez peut-être entendu parler de ), que je cite intégralement :
Cette modification a été introduite à l'origine 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, il ne semblait donc pas sensible à la sécurité à l'époque.
Je ne suis pas opposé à ce que l'on modifie ce comportement de la manière décrite par Simon, mais je m'en remets ici à l'équipe de sécurité.
Todd C. Miller, qui maintient l'amont sudo projet (très active, et ce depuis de nombreuses années), a également été sollicitée pour donner son avis sur la question. Il a répondu à l'adresse suivante : a expliqué la raison sudo réinitialise (c'est-à-dire ne préserve pas) $HOME :
Le Thu, 16 May 2019 07:48:40 -0400, Dan Streetman a écrit :
J'ai envoyé une copie aux utilisateurs de sudo, donc la question à la liste sudo en amont peut être résumée comme suit : " Je ne suis pas sûr que ce soit le cas. peut être résumée ainsi :
Quelle serait la probabilité que le sudo amont ajoute HOME à env_keep par défaut ?
Extrêmement improbable. Avant la version 1.7.4 de sudo, les variables d'environnement HOME et MAIL étaient préservées dans l'environnement par défaut. Cela peut Cela peut conduire les programmes à utiliser des fichiers de configuration dans le répertoire d'origine de l'utilisateur, ce qui a des implications en matière de sécurité. changé dans la version 1.7.4.
Dans le passé, sudo ne faisait guère plus que changer l'uid. De nos jours Aujourd'hui, sudo essaie de lancer la commande dans un environnement qui correspond qui correspond à ce que vous obtiendriez en vous connectant en tant que cet utilisateur. Cela s'est Cela s'est avéré plus sûr, car cela correspond mieux aux hypothèses que font programmes.
Nous demandons parce que Ubuntu porte un patch qui ajoute HOME à env_keep, contrairement à la version amont par défaut, ou tout autre Linux/Unix. Nous envisageons envisageons de supprimer ce correctif, afin de correspondre aux valeurs par défaut de pas incluant HOME dans env_keep.
Je serais favorable à cela. Je crois que réinitialiser HOME est le défaut le plus sûr.
- bambin
(J'ai modifié le formatage de le message original pour s'afficher correctement sur ce support).
A partir de 19.10, le en aval sudo dans Ubuntu se comporte comme la version amont sudo (et sudo dans d'autres systèmes d'exploitation, y compris Debian) se comportent depuis de nombreuses années. Pour des informations plus détaillées sur l'histoire de ce changement et les développements qui l'ont précédé, y compris de nombreux liens pour des lectures complémentaires, consultez la page " sudo y $HOME : Les 20 dernières années" ci-dessous.
Hein ? alias Pourquoi il est (parfois) important de savoir ce qu'il faut faire. sudo fait avec $HOME
Les programmes que vous exécutez et qui ont besoin de l'emplacement de votre répertoire d'origine examinent souvent la valeur de la $HOME variable d'environnement . Un cas important est celui où un programme essaie de stocker et d'accéder à les fichiers de configuration dans le répertoire personnel de l'utilisateur qui l'exécute. Les programmes prennent généralement la valeur de $HOME . Parfois, lorsque vous exécutez un programme en tant qu'utilisateur de substitution - par exemple, en tant que compte root - il est intéressant que ce programme utilise votre paramètres. Mais cela peut aussi devenir désordonné, de deux façons :
-
En général, lorsque vous exécutez une commande en tant qu'autre utilisateur, vous voulez qu'elle fonctionne à peu près 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'a exécuté - ce qui se produit si son comportement est fortement personnalisé par des données lues à partir de fichiers se trouvant dans le répertoire nommé dans l'option $HOME -- alors cet objectif n'est pas atteint.
Lorsque vous êtes autorisé à effectuer n'importe quelle action de votre choix en tant qu'utilisateur, y compris root (qui, dans Ubuntu, est conféré par l'appartenance à la communauté sudo ), la question est surtout une question d'accident. Cependant, si vous êtes un utilisateur limité et que vous avez été autorisé à exécuter le programme uniquement des commandes spécifiques con sudo alors être capable de manipuler ce que font ces commandes a de sérieuses implications en matière de sécurité. Le rapport de bogue qui a conduit à la modification de la version 19.10 a été spécifiquement motivé par ce problème (et comprend un exemple convaincant ).
-
Si vous exécutez une commande en tant qu'autre utilisateur et que la commande fait des changements à sa configuration dans le répertoire nommé dans $HOME une tentative est faite pour écrire les changements dans les fichiers de cet emplacement. Lorsque l'utilisateur de substitution n'est pas root, comme dans le cas de sudo -u **username** _command_ cette opération échoue généralement et produit des messages d'erreur, ce qui est légèrement gênant mais sans gravité.
Mais dans le cas courant où l'utilisateur de substitution est root, comme dans sudo _command_ cette opération réussit, mais si une nouveau sont créés, ils appartiennent à root, et votre compte utilisateur n'a plus un accès complet à tous ses propres fichiers de configuration. Ceci peut être corrigé par chown Le problème est donc plus grave dans le cas d'applications graphiques, dont la complexité peut faire en sorte qu'il ne soit pas possible de les récupérer. donc plus de dossiers, dans plus d'endroits, sont impliqués (et où il a été signalé pour parfois rendre la connexion difficile mais le problème est généralement moins grave que cela ).
Ce qui a changé, et pourquoi tous les systèmes 19.10 ont le changement
Une courte liste blanche de variables d'environnement qui ne sont pas réinitialisées par défaut est codée en dur dans le fichier sudo lui-même. Dans les versions d'Ubuntu antérieures à 19.10, un patch spécifique à Ubuntu ajoute $HOME à cette liste blanche. Elle est compilée dans un fichier binaire utilisé par sudo La mise à jour vers une version de sudo qui n'a pas le patch le supprime de la liste blanche.
Le patch a été supprimé dans la version 19.10 . Ainsi, la mise à jour vers la version 19.10 ou supérieure appliquera toujours le changement, même si aucun changement n'a été effectué. les fichiers de configuration associés à sudo sont modifiés.
Il est toujours possible de configurer n'importe quelle version de sudo pour préserver $HOME (voir ci-dessous). Dans le cas extrêmement inhabituel où vous avez fait cela avant 19.10 - alors qu'une telle configuration n'aurait fait aucune différence - et que vous avez conservé cette configuration lors d'une mise à jour, $HOME serait toujours préservée. Mais vous vous souviendriez sans doute avoir fait cette chose étrange.
Si votre mise à jour vers la version 19.10 (ou ultérieure) échoué et vous a donné un système seulement partiellement mis à jour avec une version de sudo d'avant 19.10, alors sudo sur ce système préserve toujours $HOME par défaut. C'est presque le seul cas où sudo préserverait $HOME dans la version 19.10 (ou ultérieure) sans que vous le sachiez - bien que vous auriez été informé, lors de la mise à niveau de la version, que tous les paquets ne pouvaient pas être mis à niveau.
La manière la plus simple de voir directement que le patch est parti 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 a https://git.launchpad.net/ubuntu/+source/sudo/tree/debian/patches?h=ubuntu/eoan .
Pourtant, si vous n'êtes pas sûr de savoir comment votre système est configuré, vous pouvez exécuter sudo printenv HOME pour le découvrir.
Réinitialisation de $HOME dans Ubuntu 19.04 et antérieures
Bien que les mises à jour de sudo dans Ubuntu 19.04 et les versions antérieures peuvent inclure des modifications de l'option documentation pour expliquer la situation, la façon sudo traite $HOME dans ces versions n'a pas été et ne sera pas modifié par les mises à jour. La plupart des utilisateurs ne voudront pas s'embêter à changer manuellement la façon dont le système de gestion de l'information est utilisé. sudo fonctionne sur des 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 à jour.
Chaque fois que vous exécutez sudo vous pouvez utiliser l'option -H / --set-home option 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 étiez connecté en tant que root, aviez exécuté command et s'est déconnecté ; sudo -i par lui-même se comporte comme si vous vous étiez connecté en tant que root et vous place dans un Shell interactif root. Ceci diffère de sudo -s , qui lance un Shell interactif qui n'est pas un Shell de connexion. Avant Ubuntu 19.10, sudo -s conserve $HOME c'est-à-dire que, quelle que soit la version, la -s ne comporte pas de comportement qui affecte la façon dont $HOME est traité. Il est utile d'utiliser -H y -s ensemble. Vous pouvez également utiliser l'un des -H , -i y -s con -u _user_ pour devenir user plutôt que la racine. Enfin, l'utilisation de sudo via les interfaces graphiques gksu o gksudo (toujours disponible dans la version 16.04 LTS, bien que vous ayez besoin d'installer l'option gksu paquet) réinitialise $HOME .
Si vous voulez reconfigurer sudo afin qu'il toujours réinitialise $HOME vous pouvez activer l'option always_set_home dans un sudoers fichier :
Defaults always_set_home
Vous devez ajouter cette ligne à /etc/sudoers ou, mieux, vers un nouveau fichier dans /etc/sudoers.d/ . Dans tous les cas, vous devez utiliser visudo pour modifier le fichier, ce qui vous permet de bénéficier du contrôle syntaxique. (Une erreur de syntaxe dans un sudoers le fichier provoque sudo de refuser de travailler du tout. C'est un problème, cependant il peut être réparé .)
Par exemple, sur certains de mes systèmes antérieurs à 19.10, j'ai créé et édité /etc/sudoers.d/_always_set_home_ en courant :
sudo visudo -f /etc/sudoers.d/always_set_home
Dans le fichier, j'ai écrit ce qui suit Defaults ligne. Le nom du fichier ne doit pas nécessairement être _always_set_home_ --Il peut s'agir de ce que vous voulez, tant qu'il ne contient pas de . o ~ caractère. Le mot sur le Defaults ligne hace doivent, bien sûr, être exactement always_set_home .
(Une raison de préférer la création d'un nouveau fichier en /etc/sudoers.d/ à la modification de l'existant /etc/sudoers est que, si une future mise à jour hace changer la valeur par défaut /etc/sudoers 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 que vous souhaitez par la suite lancer un programme individuel sudo qui préserve $HOME vous pouvez le faire de la même manière qu'en 19.10 (voir ci-dessous).
Préservation du site $HOME dans Ubuntu 19.10 et plus
La manière sudo traite $HOME a été modifié pour une raison précise. (Voir les sections ci-dessus, ainsi que la section détaillée de l'historique ci-dessous). sudo continuer à préserver $HOME Même dans les versions 19.10 et ultérieures, vous pouvez configurer ce comportement dans un fichier de configuration. sudoers fichier.
Chaque fois que vous exécutez sudo vous pouvez lui dire de préserver $HOME con --preserve-env=HOME :
sudo --preserve-env=HOME command
C'est la forme de --preserve-env qui est documenté comme --preserve-env=list en le site sudo page d'accueil . Il est également possible d'utiliser --preserve-env sans opérande de liste, ce qui est identique à -E qui préserve 何れも 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 Shell ou une fonction Shell ou écrire un Shell qui vous permet d'exécuter une commande plus courte pour le faire. Encore mieux serait de préserver rarement $HOME (voir la section ci-dessous sur les alternatives à cette démarche).
Plus généralement, vous pouvez faire sudo préserver toute variable d'environnement particulière varname con --preserve-env=_varname_ . (Vous pouvez également voir du code qui préserve efficacement $HOME en le définissant explicitement dans la commande sudo comme dans le cas de sudo HOME="$HOME" _command_ . Cela fonctionne également. C'est très différent de HOME="$HOME" sudo _command_ qui ne garderait pas sudo de la remise à zéro $HOME .)
Ou si vous vraiment veulent faire sudo toujours préserver $HOME vous pouvez le faire en ajoutant $HOME a env_keep dans un sudoers fichier :
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 de faire cela, si vous décidez de le faire, je vous suggère de créer et d'éditer /etc/sudoers.d/_keep-home_ (appelez le fichier comme vous voulez, du moment que le nom ne contient pas . o ~ ) en courant :
sudo visudo -f /etc/sudoers.d/keep-home
Alors tu peux mettre ça Defaults dans le fichier.
La raison d'utiliser += au lieu de simplement = c'est qu'il y a une poignée d'autres variables d'environnement, codées en dur dans sudo lui-même, qui sont préservés par défaut, et que vous voulez probablement préserver. Si vous avez utilisé = entonces seulement les variables d'environnement que vous avez listées explicitement dans le fichier seront préservées. Dans ce cas, ce serait juste $HOME . Plus d'informations sur la grammaire de sudoers est disponible dans sudoers(5) .
Quant à la raison pour laquelle je suggère de créer un fichier dans /etc/sudoers.d/ au lieu d'éditer /etc/sudoers --et pourquoi vous devriez absolument utiliser visudo Dans tous les cas, voir mes commentaires dans la section "Réinitialisation". $HOME dans la section "Ubuntu 19.04 et antérieures" ci-dessus.
Alternatives à la conservation $HOME
La plupart du temps, vous utilisez sudo la meilleure alternative pour préserver $HOME est de ne rien faire. La plupart des sites sudo ont le même effet (et certaines fonctionnent légèrement mieux) sans $HOME préservée. Cependant, je connais deux cas d'utilisation populaires pour la préservation des données. $HOME .
Utilisation de la configuration de votre éditeur de texte et/ou des plugins pour modifier des 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 en tant que vous vous éditez une copie temporaire du fichier, et le fichier est mis à jour lorsque vous quittez l'éditeur. Puisque l'éditeur s'exécute en votre nom, il utilise automatiquement votre configuration et vos plugins, et ce sans risque d'échouer de manière opaque et inattendue avec des erreurs de refus de permission ou de rendre inaccessibles les fichiers de votre répertoire personnel. Pour éditer file :
sudoedit file
Pour modifier file con editor au lieu de l'éditeur par défaut :
SUDO_EDITOR=editor sudoedit file
Par exemple, SUDO_EDITOR=vim sudoedit /etc/apt/sources.list éditions /etc/apt/sources.list con vim .
Pour décider de l'éditeur à utiliser, sudoedit consulte le 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 cette option n'est pas définie, il essaie d'utiliser les commandes de l'éditeur à partir d'une liste codée en dur, ce qui, en pratique, dans Ubuntu, signifie qu'il utilise les commandes suivantes editor . En général, cela se résume à /usr/bin/editor qui est un lien symbolique. Si vous voulez changer l'éditeur par défaut à l'échelle du système alors vous pouvez changer ce que /usr/bin/editor 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 changer ce qui sudoedit des modifications pour un seul utilisateur.
Faire des programmes que vous seulement exécutés en tant que root utilisent des fichiers de configuration spécifiques. Si un programme que vous exécutez en tant que root cherche 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 quand on ne sait pas quelle version on utilise
Il peut arriver que vous écriviez une commande sans savoir sur quelle version d'Ubuntu (ou sur quels systèmes d'exploitation autres qu'Ubuntu) elle fonctionnera. Par exemple, vous pouvez écrire un script que vous exécuterez sur plusieurs machines.
sudo continue d'accepter le -H avec le même effet que celui qu'il a toujours eu. Il se trouve qu'à partir de la version 19.10, sudo sans -H fait la même chose (à moins que vous ne l'ayez configuré pour faire autrement) que sudo -H .
Pour écrire des portables sudo les commandes qui réinitialisent $HOME vous pouvez continuer à l'utiliser :
sudo -H command
(De même que précédemment, si toutes les actions effectuées dans votre script doivent être faites en tant que root, il est probablement préférable de ne pas utiliser sudo dans votre script et exécutez simplement le script en tant que root avec sudo .)
sudo y $HOME : Les 20 dernières années
Au début du siècle El en amont sudo a introduit le env_reset qui rend l'option sudo 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 fichier. (Il est possible de l'activer de manière explicite, ce qui Defaults env_reset dans la version de Debian et Ubuntu /etc/sudoers le fait, mais ce n'est pas vraiment nécessaire). Avant sudo avait env_reset toutes les variables d'environnement ont été préservées sans changement. Avec env_reset seule une poignée de variables a été préservée. Il s'agit de $HOME .
En juillet 2010 , $HOME a été retiré de cette petite liste blanche et n'est donc plus préservé par défaut.
En septembre 2010 un rapport de bogue sur la documentation de ce point dans la base de données de l'UE. sudo dans Debian a été déposé. Pour autant que je sache, il n'y a pas eu de controverse ou d'objection à la modification elle-même de la part des développeurs Debian. (Mais voir ci-dessous).
En février 2011 le changement est venu plus loin en aval de Debian à Ubuntu et les développeurs d'Ubuntu ont discuté pour savoir si c'était souhaitable ou non.
En avril 2011 le changement a été signalé comme un bogue, en faisant référence à cette discussion. (Certains comportements résultant de la modification avait été signalé comme un bogue le jour d'avant). Au moins à l'époque, c'était considéré comme pour être un régression (" le responsable Debian a déjà essayé de corriger ce problème une fois mais il semble que la correction était incomplète "). Je n'ai pas trouvé un tel rapport de bogue Debian, mais cela ne veut pas dire qu'il n'y en a pas eu ; de plus, une modification aurait pu être faite sans cela. Je soupçonne cependant qu'il mai a été une référence erronée à ce bug de documentation .
Le jour suivant la version de développement d'Ubuntu a été mise à jour avec un correctif en aval, réservé à Ubuntu, pour réintégrer $HOME à la liste des variables d'environnement sudo préservée par défaut. Je pense que cela a été fait rapidement afin d'être intégré dans la version 11.04 d'Ubuntu. L'effet a été que sudo dans la 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 l'application sudo dans Ubuntu a dit $HOME a été réinitialisé. C'est-à-dire que la page de manuel d'Ubuntu décrivait correctement le comportement de l'amont. sudo mais pas le comportement corrigé dans Ubuntu.
En septembre 2014 un bogue a été signalé, soulignant certains des problèmes liés au fait d'avoir sudo préserver $HOME par défaut et en faisant valoir que le problème de l'exécution de programmes graphiques avec des programmes normaux sudo n'est pas qu'elle est intrinsèquement dangereuse (souvent citée pour cette page wiki ) mais que sudo 's traitement inhabituel de $HOME dans Ubuntu le rend dangereux et doit être considéré comme un bug. Il semble que ce rapport de bogue ait suscité un grand intérêt, y compris de la part des développeurs d'Ubuntu, même s'il faudra un certain temps avant qu'il ne soit corrigé.
En mars 2016 le bogue qui deviendra par la suite la principale référence pour les problèmes de sudo préserver $HOME a été signalé. Initialement, ce rapport de bogue se concentrait spécifiquement sur le problème de sécurité selon lequel les utilisateurs qui ne sont pas des administrateurs (c'est-à-dire qui ne peuvent pas exécuter de commandes arbitraires en tant que root), mais qui ont été autorisés à exécuter des commandes arbitraires en tant que root, ne sont pas autorisés à exécuter des commandes arbitraires. spécifique les commandes avec sudo peut modifier de manière malveillante le comportement de certains programmes et, dans certains cas, prendre le contrôle total du système. Il a recommandé un changement étroit qui tenterait de traiter ce cas spécifiquement, tout en ayant toujours $HOME préservée lorsque les membres de l sudo exécuter des commandes en tant que root ou un autre utilisateur.
En avril 2019 un bogue a été signalé concernant le comportement de la fonction sudo préserver $HOME par défaut, même lorsque sudo -s est utilisé.
Plus tard dans le mois La discussion reprend sur le thème Bug de mars 2016 vers la résolution possible de supprimer complètement le patch spécifique à Ubuntu. Cela a élargi l'objectif de ce rapport de bogue au-delà de la vulnérabilité de sécurité spécifique qu'il décrivait. L'objectif de faire sudo dans le traitement Ubuntu $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 bogue a été signalé sur la façon dont les programmes (y compris les programmes non graphiques) qui utilisent launchpadlib souffrent de problèmes de propriété du fichier de configuration, car sudo conserve $HOME .
Une semaine plus tard une autre discussion sur la liste de diffusion portant sur "la façon dont sudo gère $HOME" a eu lieu (voir aussi cette page d'archives ), présentant un éventail de points de vue sur la manière dont les sudo doit traiter $HOME . Une préférence qui n'a pas fait l'objet de controverse était que si si une modification devait être apportée, elle ne devrait concerner que les versions 19.10 et ultérieures. et ne peut être fait dans aucun mises à jour pour les versions précédentes . Le site la question s'est posée de savoir si en amont sudo continuerait à réinitialiser $HOME dans les futures versions.
Le site en amont sudo mainteneur quand consulté à ce sujet a précisé que aucune modification en amont n'est prévue et a soutenu l'idée que la version en aval de sudo dans Ubuntu devrait également réinitialiser $HOME par défaut. Ce message, posté à l'origine sur la liste de diffusion sudo-users a été cité dans un commentaire sur le rapport sur les insectes de mars 2016 .
En juin 2019 les développeurs d'Ubuntu ont prévu de supprimer le patch qui rend sudo dans Ubuntu preserve $HOME .
Environ une semaine plus tard le changement a été fait dans les dépôts d'Ubuntu. Ce changement s'applique à partir de la version 19.10. La seule modification qui sera apportée à sudo dans les versions antérieures est de mettre à jour la documentation de façon à ce qu'elle décrive clairement et correctement le comportement de la fonction sudo dans ces communiqués.
Remerciements
