|
Bugzilla – Full Text Bug Listing |
| Summary: | sudo 1.6.9p16 | ||
|---|---|---|---|
| Product: | Sudo | Reporter: | Thomas Naughton <tnaughton> |
| Component: | Sudo | Assignee: | Todd C. Miller <Todd.Miller> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | Todd.Miller |
| Priority: | normal | ||
| Version: | 1.6.9 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | Configure, install, and run example. | ||
This doesn't sound like a sudo problem. Is the behavior different if you do "su - testuser" without sudo? Yes, I can `su - testuser` (as root, and as tnaughton) without `sudo`, and I do not see the problem. The .bashrc files are as vanilla as can be (just coppied over from the base skel directory). I can ssh to the box as the testuser account and everything works fine. When I `sudo su - testuser` I'm challenged for my password, but then each character flips between the two shells. I can't type a command because it seems to want to terminate the line after each character. Also, if I flip back to version 1.6.9p16, with the same sudoers file, and user accounts, the problem goes away. As was stated in bug id# 289, that version's no longer supported, and we need the "mail_always" functionality to work. Try running configure with the following options and see if that changes the behavior:
--disable-pam-session --without-selinux
If it does, please let me know which of these was the problem.
Created attachment 224 [details]
Configure, install, and run example.
I've done the ./configure with both --disable-pam-session and --without-selinux. I still see the same behavior.
The machine is a pretty vanilla CentOS 5.1 system with selinux, and iptables both disabled:
[root@pdslchi6test1 sudo-1.6.9p16]# sestatus
SELinux status: disabled
[root@pdslchi6test1 sudo-1.6.9p16]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Here's a capture of the root user executing a `su - testuser` [root@pdslchi6test1 sudo-1.6.9p16]# su - testuser [testuser@pdslchi6test1 ~]$ ls -la total 40 drwx------ 3 testuser testgroup 4096 Jun 10 15:50 . drwxr-xr-x 4 root root 4096 Jun 10 15:49 .. -rw------- 1 testuser testgroup 22 Jun 10 16:27 .bash_history -rw-r--r-- 1 testuser testgroup 24 Jun 10 15:49 .bash_logout -rw-r--r-- 1 testuser testgroup 176 Jun 10 15:49 .bash_profile -rw-r--r-- 1 testuser testgroup 124 Jun 10 15:49 .bashrc -rw-r--r-- 1 testuser testgroup 515 Jun 10 15:49 .emacs drwxr-xr-x 3 testuser testgroup 4096 Jun 10 15:49 .kde -rw-r--r-- 1 testuser testgroup 658 Jun 10 15:49 .zshrc That looks fine. Here's a capture of the tnaughton user becomint the testuser by providing the testuser password: [tnaughton@pdslchi6test1 ~]$ su - testuser Password: [testuser@pdslchi6test1 ~]$ ls -la total 40 drwx------ 3 testuser testgroup 4096 Jun 10 15:50 . drwxr-xr-x 4 root root 4096 Jun 10 15:49 .. -rw------- 1 testuser testgroup 29 Jun 11 08:04 .bash_history -rw-r--r-- 1 testuser testgroup 24 Jun 10 15:49 .bash_logout -rw-r--r-- 1 testuser testgroup 176 Jun 10 15:49 .bash_profile -rw-r--r-- 1 testuser testgroup 124 Jun 10 15:49 .bashrc -rw-r--r-- 1 testuser testgroup 515 Jun 10 15:49 .emacs drwxr-xr-x 3 testuser testgroup 4096 Jun 10 15:49 .kde -rw-r--r-- 1 testuser testgroup 658 Jun 10 15:49 .zshrc That works fine, as well. Here, the user tnaughton attempts a `sudo su - testuser` and then will hit the following keys, exactly: "ls<RET>id<RET>w<RET>" [tnaughton@pdslchi6test1 ~]$ sudo su - testuser Password: [testuser@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ l -bash: l: command not found [testuser@pdslchi6test1 ~]$ -bash: s: command not found [tnaughton@pdslchi6test1 ~]$ [testuser@pdslchi6test1 ~]$ -bash: i: command not found [tnaughton@pdslchi6test1 ~]$ d -bash: d: command not found [testuser@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ w 08:20:10 up 18:58, 3 users, load average: 0.04, 0.02, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 10.10.10.200 Tue15 17:03m 0.02s 0.02s -bash root pts/1 10.10.10.200 08:16 0.00s 0.03s 0.00s w root pts/2 10.10.10.200 Tue15 4:35 0.06s 0.05s -bash Weird, huh? The `w` command works, but I'm kinda running out of useful one letter commands to run. ;-) Thanks for your help in this matter. I'm not able to reproduce the problem on Centos 5. Can you give sudo 1.7.0rc2 a try to see if the problem exists there? I'm planning to release 1.7.0 soon and would like to get this resolved before that. http://sudo.ws/sudo/dist/beta/sudo-1.7.0rc2.tar.gz The problem still exists: [tnaughton@pdslchi6test1 ~]$ which sudo /usr/local/bin/sudo [tnaughton@pdslchi6test1 ~]$ sudo -V Sudo version 1.7.0rc2 [tnaughton@pdslchi6test1 ~]$ sudo su - testuser Password: [testuser@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ l -bash: l: command not found [testuser@pdslchi6test1 ~]$ -bash: s: command not found [tnaughton@pdslchi6test1 ~]$ p -bash: p: command not found [testuser@pdslchi6test1 ~]$ 09:06:28 up 19:44, 3 users, load average: 0.06, 0.03, 0.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 10.10.10.200 Tue15 17:49m 0.02s 0.02s -bash root pts/1 10.10.10.200 09:03 0.00s 0.05s 0.00s w root pts/2 10.10.10.200 Tue15 50:53 0.06s 0.05s -bash [tnaughton@pdslchi6test1 ~]$ d -bash: d: command not found A little more information about the latest 1.7.0rc2 build:
[root@pdslchi6test1 ~]# which sudo
/usr/local/bin/sudo
[root@pdslchi6test1 ~]# sudo -V
Sudo version 1.7.0rc2
Sudoers path: /etc/sudoers
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: local2
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Send mail if the user is not in sudoers
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Allow some information gathering to give useful error messages
Set the LOGNAME and USER environment variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 5 minutes
Password prompt timeout: 5 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Path to mail program: /usr/sbin/sendmail
Flags for mail program: -t
Address to send mail to: root
Subject line for mail messages: *** SECURITY information for %h ***
Incorrect password message: Sorry, try again.
Path to authentication timestamp dir: /var/run/sudo
Default password prompt: Password:
Default user to run commands as: root
Path to the editor for use by visudo: /bin/vi
When to require a password for 'list' pseudocommand: any
When to require a password for 'verify' pseudocommand: all
File containing dummy exec functions: /usr/local/libexec/sudo_noexec.so
File descriptors >= 3 will be closed before executing a command
Reset the environment to a default set of variables
Environment variables to check for sanity:
TERM
LINGUAS
LC_*
LANGUAGE
LANG
COLORTERM
Environment variables to remove:
RUBYOPT
RUBYLIB
PYTHONINSPECT
PYTHONPATH
PYTHONHOME
TMPPREFIX
ZDOTDIR
READNULLCMD
NULLCMD
FPATH
PERL5DB
PERL5OPT
PERL5LIB
PERLLIB
PERLIO_DEBUG
JAVA_TOOL_OPTIONS
SHELLOPTS
GLOBIGNORE
PS4
BASH_ENV
ENV
TERMCAP
TERMPATH
TERMINFO_DIRS
TERMINFO
_RLD*
LD_*
PATH_LOCALE
NLSPATH
HOSTALIASES
RES_OPTIONS
LOCALDOMAIN
CDPATH
IFS
Environment variables to preserve:
XAUTHORIZATION
XAUTHORITY
TZ
PS2
PS1
PATH
MAIL
LS_COLORS
KRB5CCNAME
HOSTNAME
HOME
DISPLAY
COLORS
Local IP address and netmask pairs:
10.2.2.147 / 255.255.255.0
fe80::21e:bff:feda:f5e0 / ffff:ffff:ffff:ffff::
I've been reading through the diffs between 1.6.8 and 1.6.9 and I don't see anything offhand that would explain what you are seeing. However, one of the biggest changes involves how the environment is handled. Can you compare the output of: /bin/su - testuser -c set both with and without sudo to see if there is anything missing from the environment that may be triggering this? ################## WITHOUT SUDO ################## [tnaughton@pdslchi6test1 ~]$ su - testuser -c set Password: BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="1" [2]="17" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu") BASH_VERSION='3.1.17(1)-release' COLORS=/etc/DIR_COLORS.xterm CVS_RSH=ssh DIRSTACK=() DISPLAY=localhost:10.0 EUID=1001 GROUPS=() G_BROKEN_FILENAMES=1 HISTSIZE=1000 HOME=/home/testuser HOSTNAME=pdslchi6test1 HOSTTYPE=x86_64 IFS=$' \t\n' INPUTRC=/etc/inputrc KDEDIR=/usr KDE_IS_PRELINKED=1 KDE_NO_IPV6=1 LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LOGNAME=testuser LS_COLORS='no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:' MACHTYPE=x86_64-redhat-linux-gnu MAIL=/var/spool/mail/testuser OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/testuser/bin PIPESTATUS=([0]="0") PPID=952 PRELINKING=yes PRELINK_FULL_TIME_INTERVAL=14 PRELINK_NONRPM_CHECK_INTERVAL=7 PRELINK_OPTS=-mR PS4='+ ' PWD=/home/testuser QTDIR=/usr/lib64/qt-3.3 QTINC=/usr/lib64/qt-3.3/include QTLIB=/usr/lib64/qt-3.3/lib SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass TERM=xterm UID=1001 USER=testuser _=PATH consoletype=pty qt_prefix=/usr/lib64/qt-3.3 ############ WITH SUDO ############ [tnaughton@pdslchi6test1 ~]$ sudo su - testuser -c set Password: BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="1" [2]="17" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu") BASH_VERSION='3.1.17(1)-release' COLORS=/etc/DIR_COLORS.xterm CVS_RSH=ssh DIRSTACK=() DISPLAY=localhost:10.0 EUID=1001 GROUPS=() G_BROKEN_FILENAMES=1 HISTSIZE=1000 HOME=/home/testuser HOSTNAME=pdslchi6test1 HOSTTYPE=x86_64 IFS=$' \t\n' INPUTRC=/etc/inputrc KDEDIR=/usr KDE_IS_PRELINKED=1 KDE_NO_IPV6=1 LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LOGNAME=testuser LS_COLORS='no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:' MACHTYPE=x86_64-redhat-linux-gnu MAIL=/var/spool/mail/testuser OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/testuser/bin PIPESTATUS=([0]="0") PPID=1001 PRELINKING=yes PRELINK_FULL_TIME_INTERVAL=14 PRELINK_NONRPM_CHECK_INTERVAL=7 PRELINK_OPTS=-mR PS4='+ ' PWD=/home/testuser QTDIR=/usr/lib64/qt-3.3 QTINC=/usr/lib64/qt-3.3/include QTLIB=/usr/lib64/qt-3.3/lib SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass TERM=xterm UID=1001 USER=testuser _=PATH consoletype=pty qt_prefix=/usr/lib64/qt-3.3 To save you the time, I've captured the information into two separate files and the pnly difference was the PPID: [tnaughton@plslchi1test2 ~]$ diff file1 file2 36c36 < PPID=1001 --- > PPID=952 It seems like the interactive shell is giving it fits. I've tried bash, sh, and tcsh, and they all give the same results. Is there any way to get `sudo` to run in debug mode? Also: [tnaughton@pdslchi6test1 ~]$ sudo -l Matching Defaults entries for tnaughton on this host: syslog=auth, mail_always, mailto="tnaughton@peak6.com, dmusil@peak6.com", passwd_timeout=20, mailsub="SUDO %u:%h" User tnaughton may run the following commands on this host: (root) /bin/su - testuser (root) /bin/su - testuser -c set (root) /bin/su - testuser -c id [tnaughton@pdslchi6test1 ~]$ sudo /bin/su - testuser -c id uid=1001(testuser) gid=1000(testgroup) groups=1000(testgroup) [tnaughton@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ This drops me back into a normal shell as well. I've been able to reproduce the problem on CentOS 5.0 as well. In an effort to make the environment as vanilla as possible, I've installed a new CentOS 5.0 in a virtual machine. * VMware-workstation-6.0.3-80004.i386.rpm * CentOS-5.0-i386-bin-DVD.iso (basic install w/ development) * sudo-1.7.0rc2.tar Here's my /etc/sudoers file in it's entirety: --------------------------- Host_Alias TEST01 = pdslchi6test1, virtlnx1 User_Alias TESTUSER = testuser Cmnd_Alias TESTCMD1 = /bin/su - testuser Cmnd_Alias TESTCMD2 = /bin/su - testuser -c set Cmnd_Alias TESTCMD3 = /bin/su - testuser -c id Defaults syslog=auth Defaults mail_always Defaults mailto="tnaughton@peak6.com" Defaults passwd_timeout=20 Defaults mailsub="SUDO %u:%h" tnaughton TEST01=TESTCMD1 tnaughton TEST01=TESTCMD2 tnaughton TEST01=TESTCMD3 ----------------------------- The result is the same. If I attempt to su to the testuser, I'm sent into this weird situation where I can't execute any commands. This is as vanilla as I can make it. New machines, new build, new users, simple /etc/sudoers. Thanks again for your help with this. Can you try running "sudo -i -u testuser" and see if it behaves similarly? Also, is your 1.6.8p16 install (the working one) just the default Centos package? Sorry, that should be "sudo -i -H -u testuser [tnaughton@virtlnx1 ~]$ sudo -V Sudo version 1.7.0rc2 [tnaughton@virtlnx1 ~]$ sudo -i -u testuser Password: Sorry, user tnaughton is not allowed to execute '/bin/bash' as testuser on virtlnx1.peak6.com. [tnaughton@virtlnx1 ~]$ What should I have in the sudoers file to enable this? The version that's in the CentOS 5.1 standard tree is 1.6.8p12. This works for the "/bin/su - username", but will not email out when sudo is used (we need this in our environment to track user changes). 1.6.8p16 and 1.7.0rc2 both email out correctly, but they do not handle the `/bin/su - username" function. I'm now able to reproduce this. It appears that the problem is triggered by the mail_always flag. Please try running configure with the --disable-root-mailer option as a workaround. It will still send mail but the mailer will no longer run as root. Nevermind, that's not it. Please give this a try: ftp://ftp.sudo.ws/pub/millert/sudo/sudo-1.6.9p17.tar.gz Todd, This looks like a winner. I'm testing it out and it looks like the mail_always, and `su - username` quirkiness are gone completely. Thanks for your attention and work on this. Fix will appear in sudo 1.6.9p17 and sudo 1.7.0rc3 |
This is the basic setup in /etc/sudoers: -------------------- Host_Alias TEST01 = pdslchi6test1 User_Alias TESTUSER = testuser Cmnd_Alias TESTCMD = /bin/su - testuser tnaughton TEST01=/bin/su - testuser -------------------- Anytime I try to sudo to the test user, my command shell gets all wonky. It seems to be switching between the two shells. Note the "tnaughton" & "testuser" flipflop. [tnaughton@pdslchi6test1 ~]$ sudo -V | head -1 Sudo version 1.6.9p16 [tnaughton@pdslchi6test1 ~]$ sudo -l Password: User tnaughton may run the following commands on this host: (root) /bin/su - testuser [tnaughton@pdslchi6test1 ~]$ sudo su - testuser [testuser@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ k -bash: k: command not found [testuser@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ [testuser@pdslchi6test1 ~]$ [tnaughton@pdslchi6test1 ~]$ [testuser@pdslchi6test1 ~]$ -bash: j: command not found [tnaughton@pdslchi6test1 ~]$ I have to kill the window to get out.