Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#69047 - sudo 1.9.4.p1-2 handles 'sudo -i' incorrect

Attached to Project: Arch Linux
Opened by mark (qinohe) - Monday, 21 December 2020, 07:11 GMT
Last edited by Evangelos Foutras (foutrelis) - Monday, 21 December 2020, 16:08 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
sudo 1.9.4.p1-2 is vulnerable to a bug at least when using 'sudo -i'

Summary:
I'm unable to use history and my PS1 shows my hostname instead of 'root@hostname'
There may be more problems I haven't discovered.

Additional info:
I have build sudo-1.9.4.p2-1 and this version has this problem resolved.

Details:
I'm probably not the only one facing this issue.

Thanks.

This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Monday, 21 December 2020, 16:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  sudo 1.9.4.p2-2
Comment by Eric J Savadian (ejsav) - Monday, 21 December 2020, 07:59 GMT
I can't reproduce this on the same version, but I can think of some things that might narrow this down.

1) Do you get the same or similar bad behavior from `sudo su` or `sudo -s`?
2) Assuming you're running bash, after `sudo -i`, your $HISTFILE would normally be `/root/.bash_history` but your description indicates this may be blank. Can you confirm?
3) Would you mind pasting the sudo and/or audit logs from the systemd journal around when you sudo? If you have two shells running and leave `journalctl -f` up in one while you `sudo -i` in the other, you should get some lines like this:


Dec 21 07:58:35 ED-209 audit[397412]: USER_ACCT pid=397412 uid=1000 auid=1000 ses=1 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="ejsav" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Dec 21 07:58:35 ED-209 kernel: audit: type=1101 audit(1608537515.902:264): pid=397412 uid=1000 auid=1000 ses=1 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="ejsav" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Dec 21 07:58:35 ED-209 kernel: audit: type=1110 audit(1608537515.902:265): pid=397412 uid=1000 auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_faillock,pam_u2f acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Dec 21 07:58:35 ED-209 audit[397412]: CRED_REFR pid=397412 uid=1000 auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_faillock,pam_u2f acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Dec 21 07:58:35 ED-209 sudo[397412]: ejsav : TTY=pts/7 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
Dec 21 07:58:35 ED-209 sudo[397412]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Dec 21 07:58:35 ED-209 audit[397412]: USER_START pid=397412 uid=1000 auid=1000 ses=1 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Dec 21 07:58:35 ED-209 kernel: audit: type=1105 audit(1608537515.912:266): pid=397412 uid=1000 auid=1000 ses=1 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Comment by mark (qinohe) - Monday, 21 December 2020, 08:22 GMT
Hi Eric, thanks for replying.
1. 'sudo su is okay 'sudo -s shows the same behavior.
2. I'm starting from a zsh shell and yes root runs bash.
SHELL=/bin/bash
SUDO_COMMAND=/usr/bin/zsh
3. Dec 21 09:13:46 asterope audit[246288]: USER_ACCT pid=246288 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="mark" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/15 res=success'
Dec 21 09:13:46 asterope audit[246288]: CRED_REFR pid=246288 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/15 res=success'
Dec 21 09:13:46 asterope sudo[246288]: mark : TTY=pts/15 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/zsh
Dec 21 09:13:46 asterope sudo[246288]: pam_unix(sudo:session): session opened for user root(uid=0) by mark(uid=1000)
Dec 21 09:13:46 asterope audit[246288]: USER_START pid=246288 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/15 res=success'
Dec 21 09:13:50 asterope sudo[246288]: pam_unix(sudo:session): session closed for user root
Dec 21 09:13:50 asterope audit[246288]: USER_END pid=246288 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:session_close grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/15 res=success'
Dec 21 09:13:50 asterope audit[246288]: CRED_DISP pid=246288 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/15 res=success'
Comment by mark (qinohe) - Monday, 21 December 2020, 08:28 GMT
And yes and my populated history is blank ( arrow up/down ), though, .bash_history is okay.
Comment by Eric J Savadian (ejsav) - Monday, 21 December 2020, 12:48 GMT
Someone else reported this in IRC (roughly an hour ago) and was also running zsh as their user login shell.
Comment by johnLate (johnLate) - Monday, 21 December 2020, 13:51 GMT
Same problem here (1.9.4.p1-2). Downgrading only the sudo package to 1.9.4-1 "fixes" it, but sudo is not the kind of package I want to pin to an old version.

When user2 (bash) runs «sudo -i» a bash is started for root despite:

# getent passwd root
root:x:0:0:root:/root:/bin/zsh

«SHELL=/bin/zsh sudo -i» starts a zsh for root.

Loading...