Your message dated Fri, 9 Jul 2021 17:17:29 +0200 with message-id <[email protected]> and subject line Re: Bug#523882: sudo -i doesn't unset some environment variables has caused the Debian Bug report #523882, regarding sudo -i doesn't unset some environment variables to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 523882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523882 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: sudo Version: 1.6.9p17-2 Severity: normal The sudo man page says: -i The -i (simulate initial login) option runs the shell specified in the passwd(5) entry of the user that the command is being run as. The command name argument given to the shell begins with a `-' to tell the shell to run as a login shell. sudo attempts to change to that user's home directory before running the shell. It also ini- tializes the environment, leaving TERM unchanged, setting HOME, SHELL, USER, LOGNAME, and PATH, and unsetting all other environment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ variables. Note that because the shell to use is determined before ^^^^^^^^^ the sudoers file is parsed, a runas_default setting in sudoers will specify the user to run the shell as but will not affect which shell is actually run. But I get: ay:/home/lefevre# sudo -i ay:~# env SHELL=/bin/bash TERM=xterm-color XAPPLRESDIR=/home/lefevre/.app-defaults USER=root LS_COLORS=no=00:di=01;32:ln=01;36:pi=01;34:so=01;35:bd=01;31:cd=01;31:ex=01;33 SUDO_USER=root SUDO_UID=0 USERNAME=root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 MAIL=/var/mail/root LC_COLLATE=POSIX PWD=/root LANG=POSIX LC_CHARMAP=ISO-8859-1 XFILESEARCHPATH=/home/lefevre/.app-defaults PS1=\h:\w\$ SHLVL=1 SUDO_COMMAND=/bin/bash HOME=/root LOGNAME=root LC_CTYPE=en_US.ISO8859-1 SUDO_GID=0 LC_TIME=en_DK COLORTERM=xterm-color _=/usr/bin/env while /root/.bashrc just sets PS1 amd /root/.profile just sets PATH. Note that the values of XAPPLRESDIR, LC_CHARMAP and XFILESEARCHPATH can only come from my user (lefevre) settings; this means that even if global config files have been run (I couldn't see in strace -f output), this cannot explain these 3 values, i.e. these 3 values have never been unset. My /etc/sudoers file doesn't set any option. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable'), (500, 'oldstable'), (200, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-powerpc Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages sudo depends on: ii libc6 2.9-4 GNU C Library: Shared libraries ii libpam-modules 1.0.1-9 Pluggable Authentication Modules f ii libpam0g 1.0.1-9 Pluggable Authentication Modules l sudo recommends no packages. sudo suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---Version: 1.9.5p2-3 On 2021-02-24 21:47:54 +0100, Marc Haber wrote: > Would it be ok for you to check current sudo's behavior, compare it with > the docs and explain whether it's buggy and how? The man page has changed. About the environment, it just says now (with sudo 1.9.5p2-3): "The command is run with an environment similar to the one a user would receive at log in." I suppose that it is fine to have not too many details (at least, this will less likely to be wrong). One should just ensure that the default is sane and consistent. And the default seems OK. All the locale-related variables (LANG, LANGUAGE, LC_*) are kept, but I think that this is the expected behavior. sudo might just unset a bit too much: $TERMINFO is unset, while it is closely related to $TERM, which is kept. Let's hope that ncurses won't introduce incompatible changes in the future (like what has been done in the past), otherwise this will yield unfixable issues when ssh'ing to a machine with incompatible terminfo data. But I'd say that this would be a bug different from this one. So I'm closing it. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- End Message ---
