[Bug 1992025] [NEW] When sudo does not require a password, it alters stty as though it is reading a password

Launchpad Bug Tracker 1992025 at bugs.launchpad.net
Mon Oct 10 10:16:59 UTC 2022


You have been subscribed to a public bug by Julian Andres Klode (juliank):

Summary:
Executing a sudo (that does not require a password) in a /bin/bash script leaves the terminal as though it is reading a password (-echo, -icrnl, -ixon, -opost, -isig, -icanon, -iexten)

To recreate the problem: (See attached log)

In a fresh install of 22.04.1 (desktop, minimal, do not load updates, no
update done beyond iso data, running under Virtualbox on a Mac), I set
up a new user that can run "sudo sleep" without a password.  In a
Terminal, I demonstrate this, running "stty -a" before and after the
"sudo sleep". Then I create a bash script with those same commands.
When that script is run, the stty after the "sudo sleep" shows that the
state of the terminal has been altered (-echo, etc.)

The log starts immediately after the reboot after installing 22.04.1. I
decline to do the update when it is offered. (The bug appears even if I
do the update on 22.04.1, but I decline the update to make sure this is
repeatable.)

Basically, the steps are
  Create user "testuser"
  Add a file to /etc/sudoers.d that gives testuser sudo privs, with no password required for sleep.  (nor for "grep", but I dropped the use of grep in the demo)
  su - testuser
  Interactively, in the terminal, I show that "sudo sleep 30 &"  does not mess with the terminal settings.
  I create a /bin/bash script that includes the same commands (stty -a; sudo sleep 10 &; sleep 3; stty -a)
  I execute the script, which alters the terminal settings.(Quite visible on the Terminal; not as easily visible in the log file.)


I expect the second "stty -a" to be the same as the first.

I originally saw the bug in 20.04.5 (repeatable but on someone else's
computer) for "sudo tcpdump" but wasn't able to reproduce it in a fresh
install.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: sudo 1.9.9-1ubuntu2
ProcVersionSignature: Ubuntu 5.15.0-48.54-generic 5.15.53
Uname: Linux 5.15.0-48-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct  6 10:40:03 2022
InstallationDate: Installed on 2022-10-06 (0 days ago)
InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: sudo
UpgradeStatus: No upgrade log present (probably fresh install)
VisudoCheck:
 Error: command ['pkexec', '/usr/sbin/visudo', '-c'] failed with exit code 1: /etc/sudoers.d/testuser: bad permissions, should be mode 0440
 /etc/sudoers: parsed OK
 /etc/sudoers.d/README: parsed OK
modified.conffile..etc.sudoers: [inaccessible: [Errno 13] Permission denied: '/etc/sudoers']
modified.conffile..etc.sudoers.d.README: [inaccessible: [Errno 13] Permission denied: '/etc/sudoers.d/README']

** Affects: sudo (Ubuntu)
     Importance: Medium
         Status: Triaged

** Affects: sudo (Ubuntu Jammy)
     Importance: Medium
         Status: Confirmed

** Affects: sudo (Ubuntu Kinetic)
     Importance: Medium
         Status: Triaged


** Tags: amd64 apport-bug jammy wayland-session
-- 
When sudo does not require a password, it alters stty as though it is reading a password
https://bugs.launchpad.net/bugs/1992025
You received this bug notification because you are a member of Ubuntu Foundations Bugs, which is subscribed to the bug report.



More information about the foundations-bugs mailing list