I have SUDO_PS1 set to a personal preference. Previously, running "sudo su" would get me into a root state, having set PS1 to SUDO_PS1, as documented in "man sudo". This no longer happens. SUDO_PS1 exists in the new environment, however, so it is not being lost. Reproducible: Always Steps to Reproduce: 1. export SUDO_PS1=testing 2. sudo su 3. echo $SUDO_PS1 4. echo $PS1 Actual Results: $ export SUDO_PS1=testing $ sudo su xoanon build-Linux-i386 # echo $SUDO_PS1 testing xoanon build-Linux-i386 # echo $PS1 \[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\] Expected Results: $ export SUDO_PS1=testing $ sudo su testing # Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5,dev-lang/python-2.2.3-r5 [2.3.5 (#1, May 3 2005, 09:35:30)] dev-lang/python: 2.3.5, 2.2.3-r5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.4.19-r1, 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm avi berkdb bitmap-fonts cdr crypt cups curl dvd emboss encode esd fam foomaticdb fortran gdbm gif gpm gtk gtk2 imlib ipv6 java jpeg junit ldap libg++ libwww mad mikmod motif mp3 mpeg mysql ncurses nls nptl ogg oggvorbis opengl oss pam pcre pdflib perl png python quicktime readline sdl slang spell ssl svga tcpd tiff truetype truetype-fonts type1-fonts vorbis xml xml2 xmms xv zlib video_cards_matrox userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
sounds like a bug in sudo rather than bash ... especially since the source code of bash-2/bash-3 do not contain the string 'SUDO' ...
$ SUDO_PS1=hello sudo /usr/bin/env | grep PS1 SUDO_PS1=hello PS1=hello $ SUDO_PS1=hello sudo /bin/sh $ helloexit exit $ SUDO_PS1=hello sudo /bin/ksh helloexit What versions of sudo/bash did this used to work with?
It works fine with Sudo version 1.6.7p5 GNU bash, version 2.05b.0(1)-release-(i686-pc-linux-gnu)
Oh, also note that SUDO_PS1=hello sudo /usr/bin/env | grep PS1 works. Things go wrong when I obey "sudo su" in order to get an interactive root shell. In other words, if I obey SUDO_PS1=hello sudo su followed by /usr/bin/env | grep PS1 in the new state. That's why I tried to implicate bash 3.00. :-)
Hmm, i dont know whos to blame for this one...i'll look into it :)
stale but still reproducable for me ;)
The problem is that /etc/profile.env and /etc/bash/bashrc reset PS1, even if sudo sets it. The only way to fix this is to check if PS1 is set already before re-setting it.
Forgive for barging in so late, but this I would say is a DONTFIX. PS1 should never be honoured when doing sudo, but always set by root to something else, for security reasons. Many, if not most distros do the Wrong Thing here, and I don't want to see Gentoo repeat this mistake. Example: export SUDO_PS1='`[ -r /etc/shadow ] && cat /etc/shadow >/tmp/foo``pwd` # ' CTRL-L "Hoy, admin, can you mount this CD for me to /mnt/cdrom instead of /media/cdrom? The program is cranky about the path..." [ user@fedora ~] % su adminuser Password: [ adminuser@fedora ~] % sudo su [sudo] password for adminuser: /home/adminuser # mount /dev/cdrom /mnt/cdrom /home/adminuser # [CTRL-D] [ adminuser@fedora ~] % [CTRL-D] [ user@fedora ~] % There's now a copy of /etc/shadow in /tmp. The variations of this exploit are endless, and the fix is to never trust environment variables from a user (which the admin user could have avoided by using "su - adminuser" instead of "su adminuser").
i tend to agree with Arthur. this is not a sane default. if sudo is fixed to not respect SUDO_PS1 by default (i.e. require a config option in /etc/sudoers), then i'll review the bash changes to make this work.
AFAICS it's not respected by sudo but I'll have to talk with Todd about it.
seems it does it for me: $ SUDO_PS1=asdf sudo env | grep asdf PS1=asdf and reading env.c shows there are no checks on it
