Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #261846 > unrolled thread

apt-get aborts in subshell with redirections on Debian 12

Back to article view | Back to linux.debian.user

Contents

  apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-24 09:40 +0200
    Re: apt-get aborts in subshell with redirections on Debian 12 Michel Verdier <mv524@free.fr> - 2023-09-24 12:10 +0200
      Re: apt-get aborts in subshell with redirections on Debian 12 Greg Wooledge <greg@wooledge.org> - 2023-09-24 14:40 +0200
        Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-25 02:20 +0200
          Re: apt-get aborts in subshell with redirections on Debian 12 Greg Wooledge <greg@wooledge.org> - 2023-09-25 02:40 +0200
            Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-25 05:00 +0200
              Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-25 05:20 +0200
              Re: apt-get aborts in subshell with redirections on Debian 12 Greg Wooledge <greg@wooledge.org> - 2023-09-25 05:50 +0200
                Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-25 06:40 +0200
                  Re: apt-get aborts in subshell with redirections on Debian 12 Greg Wooledge <greg@wooledge.org> - 2023-09-25 13:30 +0200
                    Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-26 04:40 +0200
                Re: apt-get aborts in subshell with redirections on Debian 12 Michael <ml@hemathor.de> - 2023-09-25 11:20 +0200
                  Re: apt-get aborts in subshell with redirections on Debian 12 Greg Wooledge <greg@wooledge.org> - 2023-09-25 13:30 +0200
                    Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-26 05:00 +0200
                      Re: apt-get aborts in subshell with redirections on Debian 12 Greg Wooledge <greg@wooledge.org> - 2023-09-26 05:10 +0200
                        Re: apt-get aborts in subshell with redirections on Debian 12 John Crawley <john@bunsenlabs.org> - 2023-09-26 05:20 +0200
                      sudo+use_pty+urxvt+pipe [WAS: apt-get aborts in subshell with  redirections on Debian 12] John Crawley <john@bunsenlabs.org> - 2023-12-24 09:50 +0100

#261846 — apt-get aborts in subshell with redirections on Debian 12

Hi folks,

I've just about run out of ideas here, so appealing for suggestions.
I don't know if this is a change in the behaviour of apt or bash, or both, between Debian 11 and 12.

I have a script which is supposed to smooth out some apt actions, while still keeping user interactions, but with the upgrade to Debian Bookworm some apt prompts are aborting immediately. Any apt errors are stored in a variable for checking over. I'll paste the full function below for those who are curious - but this simple command will illustrate:

errors=$( sudo apt-get install mirage 2>&1 1>/dev/tty )
echo "$errors"

(Replace 'mirage' with 'mirag' to see some content in $errors, and anyway choose a package you don't already have installed and which will bring in some dependencies, so apt will prompt to continue.)

On Debian 12, I get:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
   gir1.2-gexiv2-0.10 libexiv2-27 libgexiv2-2
Suggested packages:
   exiv2 gimp imagemagick
The following NEW packages will be installed:
   gir1.2-gexiv2-0.10 libexiv2-27 libgexiv2-2 mirage
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,761 kB of archives.
After this operation, 8,250 kB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.

Going straight to "Abort" which is what happens if apt has no stdin. But surely it does?

Running the same command on Debian 11 works as expected, waiting for USER response at the prompt.

Also, even on Debian 12, the command does not abort if run on dash instead of bash.

This works OK too:

( sudo apt-get install mirage 2>&1 1>/dev/tty )

It's only when stderr is captured that the abort is triggered.

If there's no nice workaround I'll switch to making a temp file and put stderr there instead. Not elegant, but this works:

tmp=$(mktemp)
sudo apt-get install mirage 2> $tmp
errors=$(<$tmp)

FWIW this is the original bash function (maybe no longer needed anyway) which used to work on Bullseye but not on Bookworm:

# Usage safeInstall [--apt-get-option] package [package...]
safeInstall() {
     local ignore_string_pw='Sorry, try again.' # message if password mistyped
     local ignore_string1='Extracting templates from packages: 100%' # apt sends this to stderr!
     local ignore_string2='Retrieving bug reports... Done' # apt-listbugs sends this to stderr!
     local ignore_string3='Parsing Found/Fixed information... Done' # apt-listbugs sends this to stderr!
     local apt_error
     if exec 3>&1; apt_error=$(LC_MESSAGES=C sudo apt-get install "${@}" 2>&1 1>&3) && {
             [[ -z "$apt_error" ]] || ! grep -iqEv "(${ignore_string_pw:-$^}|${ignore_string1:-$^}|${ignore_string2:-$^}|${ignore_string3:-$^}|^$)" <<<"$apt_error"
             }
     then
         exec 3>&-
         say 'Installation finished sucessfully.' 1
         return 0
     else
         exec 3>&-
         errorExit "There were problems installing ${*}" "${apt_error:-Install Aborted}"
         return 1
     fi
}

-- 
John

[toc] | [next] | [standalone]

#261849

On 2023-09-24, John Crawley wrote:

> errors=$( sudo apt-get install mirage 2>&1 1>/dev/tty )
> echo "$errors"

#!/bin/bash
errors=$(sudo apt-get install unknown 2>&1 1>/dev/tty)
echo "output: $errors"
errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
echo "output: $errors"

debian version 12.1
ii  apt                 2.6.1        amd64 
ii  bash            5.2.15-2+b2  amd64 
ii  sudo           1.9.13p3-1+deb12u1 amd64

> Going straight to "Abort" which is what happens if apt has no stdin. But surely it does?
>
> Running the same command on Debian 11 works as expected, waiting for USER response at the prompt.

# ./test 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
output: E: Unable to locate package unknown
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  gir1.2-gexiv2-0.10
The following NEW packages will be installed:
  gir1.2-gexiv2-0.10 mirage
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 120 kB of archives.
After this operation, 649 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
output: 

It waits until I type 'n'

Perhaps you have another command disturbing tty ?
Or check sudo ?

[toc] | [prev] | [next] | [standalone]

#261851

On Sun, Sep 24, 2023 at 12:03:12PM +0200, Michel Verdier wrote:
> #!/bin/bash
> errors=$(sudo apt-get install unknown 2>&1 1>/dev/tty)
> echo "output: $errors"
> errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
> echo "output: $errors"
> 
> [...]
> It waits until I type 'n'

Same here.

[toc] | [prev] | [next] | [standalone]

#261876

On 24/09/2023 21:36, Greg Wooledge wrote:
> On Sun, Sep 24, 2023 at 12:03:12PM +0200, Michel Verdier wrote:
>> #!/bin/bash
>> errors=$(sudo apt-get install unknown 2>&1 1>/dev/tty)
>> echo "output: $errors"
>> errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
>> echo "output: $errors"
>>
>> [...]
>> It waits until I type 'n'
> 
> Same here.
> 
Thanks for testing.

I just tried, and yes it runs OK when the commands are in a script.
But type directly into the terminal:

errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)

To see the immediate abort.
(But not on Debian 11, or after invoking 'sh'.)

-- 
John

[toc] | [prev] | [next] | [standalone]

#261877

On Mon, Sep 25, 2023 at 09:10:28AM +0900, John Crawley wrote:
> On 24/09/2023 21:36, Greg Wooledge wrote:
> > On Sun, Sep 24, 2023 at 12:03:12PM +0200, Michel Verdier wrote:
> > > #!/bin/bash
> > > errors=$(sudo apt-get install unknown 2>&1 1>/dev/tty)
> > > echo "output: $errors"
> > > errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
> > > echo "output: $errors"
> > > 
> > > [...]
> > > It waits until I type 'n'
> > 
> > Same here.
> > 
> Thanks for testing.
> 
> I just tried, and yes it runs OK when the commands are in a script.
> But type directly into the terminal:
> 
> errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
> 
> To see the immediate abort.
> (But not on Debian 11, or after invoking 'sh'.)

I actually tested in a terminal, not with a script.  But the fact that
*you* are getting different results with a script vs. a terminal is a
clue.  It doesn't give us a complete answer, but it's definitely a
significant observation.

The first thing you'll want to check is "type sudo", in your shell.

unicorn:~$ type sudo
sudo is hashed (/usr/bin/sudo)

If yours is an alias, or a function, or comes from some other directory,
that might explain the difference you see when running in a terminal.

If that doesn't give any further clues, you might look for unusual
configuration in your interactive shell.  Things like a DEBUG trap,
or the PROMPT_COMMAND or PS0 variables, which might trigger surprises
when running commands, would be good to know about.

You could also try a few experiments:

1) Run "bash --noprofile --norc" to get a vanilla shell, without any
   aliases, functions, weird shopts, etc.  See if you still get the
   undesired results.

2) Try in dash, ksh, zsh or whatever other shells you have.  See if you
   get the undesired results in any shell other than bash.  (It looks
   like you already tried in dash, assuming sh -> dash.)

3) Create a new user account with only the default dotfiles, and see
   if you get the undesired results there.  (You may have to add it to
   the sudo group.)

[toc] | [prev] | [next] | [standalone]

#261878

Thanks for the ideas!

On 25/09/2023 09:36, Greg Wooledge wrote:
> On Mon, Sep 25, 2023 at 09:10:28AM +0900, John Crawley wrote:
>> I just tried, and yes it runs OK when the commands are in a script.
>> But type directly into the terminal:
>>
>> errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
>>
>> To see the immediate abort.
>> (But not on Debian 11, or after invoking 'sh'.)
> 
> I actually tested in a terminal, not with a script.  But the fact that
> *you* are getting different results with a script vs. a terminal is a
> clue.  It doesn't give us a complete answer, but it's definitely a
> significant observation.
> 
> The first thing you'll want to check is "type sudo", in your shell.
> 
> unicorn:~$ type sudo
> sudo is hashed (/usr/bin/sudo)

sudo is hashed (/usr/bin/sudo)

> If that doesn't give any further clues, you might look for unusual
> configuration in your interactive shell.  Things like a DEBUG trap,
> or the PROMPT_COMMAND or PS0 variables, which might trigger surprises
> when running commands, would be good to know about.

I don't think I've added anything like that - this is a fairly new test install.
I tried logging into a Ctrl+Alt+F2 tty and got the same results.
For a moment I thought it might be because it's a Qemu VM, so dragged out my old test laptop and the results are the same.

The only thing I can think of right now is that this (VM and laptop both) is an i386 system. Could it be bash is missing some 32 bit update?

Anyway, I tried these:

> 1) Run "bash --noprofile --norc" to get a vanilla shell, without any
>     aliases, functions, weird shopts, etc.  See if you still get the
>     undesired results.

Same undesired result.

> 2) Try in dash, ksh, zsh or whatever other shells you have.  See if you
>     get the undesired results in any shell other than bash.  (It looks
>     like you already tried in dash, assuming sh -> dash.)

Dash is OK. I installed and tried ksh and zsh and there was no problem there either.

> 3) Create a new user account with only the default dotfiles, and see
>     if you get the undesired results there.  (You may have to add it to
>     the sudo group.)

adduser tmp
adduser tmp sudo

Log in to tmp (no graphical session set up), and the results are the same: behaviour in a bash shell is wrong, everything else works.

So the 32bit system is different??

-- 
John

[toc] | [prev] | [next] | [standalone]

#261882

On 25/09/2023 11:58, John Crawley wrote:
> 
> So the 32bit system is different??
> 

Doesn't semm to be that.
amd64 Bookworm VM behaves the same way.

-- 
John

[toc] | [prev] | [next] | [standalone]

#261883

On Mon, Sep 25, 2023 at 11:58:13AM +0900, John Crawley wrote:
> adduser tmp
> adduser tmp sudo
> 
> Log in to tmp (no graphical session set up), and the results are the same: behaviour in a bash shell is wrong, everything else works.

I simply can't reproduce your results at all.

unicorn:~$ sudo adduser test2
[...]
unicorn:~$ sudo adduser test2 sudo
[...]
unicorn:~$ su - test2
Password: 
test2@unicorn:~$ id
uid=1001(test2) gid=1001(test2) groups=1001(test2),27(sudo),100(users)
test2@unicorn:~$ errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
[sudo] password for test2: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  gir1.2-gexiv2-0.10 gir1.2-gtk-3.0 libexiv2-27 libgexiv2-2 python3-cairo
  python3-gi python3-gi-cairo
Suggested packages:
  exiv2 gimp
The following NEW packages will be installed:
  gir1.2-gexiv2-0.10 gir1.2-gtk-3.0 libexiv2-27 libgexiv2-2 mirage
  python3-cairo python3-gi python3-gi-cairo
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,249 kB of archives.
After this operation, 10.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
test2@unicorn:~$ 

This leaves me very confused.  There's something different about your
systems compared to mine (and the other person who also could not
reproduce your results), but damned if I can guess *what*.

The only other experiment I can think of at this time would be:

4) In a bash shell as root (e.g. "su" or "sudo -s"), do:

   errors=$(apt-get install mirage 2>&1 1>/dev/tty)

This removes sudo from the picture.  But I don't know what the results
will tell us.

I can generate the *message* that you get by redirecting stdin:

unicorn:~$ sudo apt-get install mirage 0</dev/null
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  gir1.2-gexiv2-0.10 gir1.2-gtk-3.0 libexiv2-27 libgexiv2-2 python3-cairo
  python3-gi python3-gi-cairo
Suggested packages:
  exiv2 gimp
The following NEW packages will be installed:
  gir1.2-gexiv2-0.10 gir1.2-gtk-3.0 libexiv2-27 libgexiv2-2 mirage
  python3-cairo python3-gi python3-gi-cairo
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,249 kB of archives.
After this operation, 10.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.

But there's nothing you've shown that's redirecting stdin, so I don't
know whether this is what's causing your problem or not.  If it *is*
what's causing your problem, I still don't have a clue what's *doing*
it.

Is there any unusual configuration of sudo on your system?  Sudo
configuration is utterly baffling, and about 2 orders of magnitude more
stupidly complex than it should be, so I don't even know what kind of
atrocities are *possible* in sudoers, let alone which of them might be
capable of doing something insane like closing stdin on commands run
via sudo.  But if you've changed anything in sudoers or sudoers.d you
might want to report on those changes.

(But why would this only happen when sudo's parent is bash?  None of
this makes *any* sense.)

[toc] | [prev] | [next] | [standalone]

#261884

On 25/09/2023 12:42, Greg Wooledge wrote:
> On Mon, Sep 25, 2023 at 11:58:13AM +0900, John Crawley wrote:
>> adduser tmp
>> adduser tmp sudo
>>
>> Log in to tmp (no graphical session set up), and the results are the same: behaviour in a bash shell is wrong, everything else works.
> 
> I simply can't reproduce your results at all.

This is so weird. There's probably some simple explanation somewhere...

I have a freshly installed Bookworm netinstall CLI system among my VMs. Only "standard system utilities" added during the install process. Restored the just-after-install snapshot, did an apt update/upgrade, and:

$ id
uid=1000(john) gid=1000(john) groups=1000(john),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev)

Is there a hint here? Those are the default groups I was put in by the Debian Installer, but it's a much longer list than yours.

Anyway 'errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)' wrote a long list of dependencies (of course) but then aborted as usual.

> This leaves me very confused.  There's something different about your
> systems compared to mine (and the other person who also could not
> reproduce your results), but damned if I can guess *what*.
> 
> The only other experiment I can think of at this time would be:
> 
> 4) In a bash shell as root (e.g. "su" or "sudo -s"), do:
> 
>     errors=$(apt-get install mirage 2>&1 1>/dev/tty)

-bash: syntax error near unexpected token `2'

So bash as root has a problem with the redirection.

But this worked OK in the same root shell:

exec 3>1
errors=$( apt-get install mirage 2>&1 1>&3 )
exec 3>&-

If 'mirage' is replaced with 'mirag' then $errors holds the error message.

So at least something is working!

Maybe it is an issue with sudo?

> I can generate the *message* that you get by redirecting stdin:
> 
> But there's nothing you've shown that's redirecting stdin, so I don't
> know whether this is what's causing your problem or not.  If it *is*
> what's causing your problem, I still don't have a clue what's *doing*
> it.
> 
> Is there any unusual configuration of sudo on your system?  Sudo
> configuration is utterly baffling, and about 2 orders of magnitude more
> stupidly complex than it should be, so I don't even know what kind of
> atrocities are *possible* in sudoers, let alone which of them might be
> capable of doing something insane like closing stdin on commands run
> via sudo.  But if you've changed anything in sudoers or sudoers.d you
> might want to report on those changes.

No. Those last tests were done on a freshly installed Bookworm netinstall VM, no changes apart from apt updating.

> (But why would this only happen when sudo's parent is bash?  None of
> this makes *any* sense.)

I just hope I haven't been making an awful stupid mistake all along...

-- 
John

[toc] | [prev] | [next] | [standalone]

#261897

On Mon, Sep 25, 2023 at 01:35:38PM +0900, John Crawley wrote:
> > 4) In a bash shell as root (e.g. "su" or "sudo -s"), do:
> > 
> >     errors=$(apt-get install mirage 2>&1 1>/dev/tty)
> 
> -bash: syntax error near unexpected token `2'
> 
> So bash as root has a problem with the redirection.

At this point I'm guessing you made a typo.  Since you didn't show us
the command you typed, that's my official guess.  Any alternative is
too far beyond belief.

> But this worked OK in the same root shell:
> 
> exec 3>1
> errors=$( apt-get install mirage 2>&1 1>&3 )
> exec 3>&-
> 
> If 'mirage' is replaced with 'mirag' then $errors holds the error message.
> 
> So at least something is working!

Note your typo in the first exec command.  You've got FD 3 redirected
to a file named '1', rather than dup-ing stdout.

> Maybe it is an issue with sudo?

According to Michael's discovery, yes.

[toc] | [prev] | [next] | [standalone]

#261926

Many thanks to Michael for finding the change in sudo behaviour!

For historical accuracy:
On 25/09/2023 20:24, Greg Wooledge wrote:
> On Mon, Sep 25, 2023 at 01:35:38PM +0900, John Crawley wrote:
>>> 4) In a bash shell as root (e.g. "su" or "sudo -s"), do:
>>>
>>>      errors=$(apt-get install mirage 2>&1 1>/dev/tty)
>>
>> -bash: syntax error near unexpected token `2'
>>
>> So bash as root has a problem with the redirection.
> 
> At this point I'm guessing you made a typo.  Since you didn't show us
> the command you typed, that's my official guess.  Any alternative is
> too far beyond belief.

It must have been a typo.
I should have copy-pasted the command, which was at that point possible, but anyway that syntax error no longer appears.

>> But this worked OK in the same root shell:
>>
>> exec 3>1
>> errors=$( apt-get install mirage 2>&1 1>&3 )
>> exec 3>&-
>>
>> If 'mirage' is replaced with 'mirag' then $errors holds the error message.
>>
>> So at least something is working!
> 
> Note your typo in the first exec command.  You've got FD 3 redirected
> to a file named '1', rather than dup-ing stdout.

Oops, sorry. With corrected commands it still works, even with default "use_pty" in sudoers.

So running in a root shell, the new setting does not interfere. Clearly sudo only.

-- 
John

[toc] | [prev] | [next] | [standalone]

#261887

hey,

i was curious, so i tried it on the only machine i have sudo installed on, 
which is my Debian based Ubuntu based LinuxMint Laptop.

  micha@HP-Laptop: ~
  > errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
  [sudo] password for micha:                    
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following additional packages will be installed:
    gir1.2-gexiv2-0.10
  The following NEW packages will be installed:
    gir1.2-gexiv2-0.10 mirage
  0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
  Need to get 111 kB of archives.
  After this operation, 648 kB of additional disk space will be used.
  Do you want to continue? [Y/n] Abort.

then i switched to a shell, opened i with 'sudo tmux'

root@HP-Laptop: ~
# errors=$(apt-get install mirage 2>&1 1>/dev/tty)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  gir1.2-gexiv2-0.10
The following NEW packages will be installed:
  gir1.2-gexiv2-0.10 mirage
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 111 kB of archives.
After this operation, 648 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

so i looked into /etc/sudoers and all /etc/sudoers.d/* and found two 
suspicous flags:

/etc/sudoers:
Defaults       use_pty

/etc/sudoers.d/0pwfeedback:
Defaults pwfeedback

then consulting the sudo manpage convinced me, it was the 'use_pty' flag 
(in section SUDOERS OPTIONS). after removing that flag everything works as 
'expected':

  micha@HP-Laptop: ~
  > errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
  [sudo] password for micha:                    
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following additional packages will be installed:
    gir1.2-gexiv2-0.10
  The following NEW packages will be installed:
    gir1.2-gexiv2-0.10 mirage
  0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
  Need to get 111 kB of archives.
  After this operation, 648 kB of additional disk space will be used.
  Do you want to continue? [Y/n] n
  Abort.

hth.

greetings...

[toc] | [prev] | [next] | [standalone]

#261896

On Mon, Sep 25, 2023 at 11:14:24AM +0200, Michael wrote:
> so i looked into /etc/sudoers and all /etc/sudoers.d/* and found two
> suspicous flags:
> 
> /etc/sudoers:
> Defaults       use_pty
> 
> /etc/sudoers.d/0pwfeedback:
> Defaults pwfeedback
> 
> then consulting the sudo manpage convinced me, it was the 'use_pty' flag (in
> section SUDOERS OPTIONS). after removing that flag everything works as
> 'expected':

Well, that is quite the find.  My systems are not freshly installed
Debian 12, but rather upgraded from previous releases.

Given the presence of an /etc/sudoers.dpkg-dist file on my system,
which does in fact contain this:

# This fixes CVE-2005-4890 and possibly breaks some versions of kdesu
# (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)
Defaults        use_pty

it looks like you've solved *most* of the mystery.  I still don't get
why it matters whether the command was executed from bash or dash --
maybe bash sets up the file descriptors differently when performing
a command substitution, in a way that has a subtle interaction surprise
with sudo's use_pty option.  I don't know.

[toc] | [prev] | [next] | [standalone]

#261927

On 25/09/2023 20:21, Greg Wooledge wrote:
> On Mon, Sep 25, 2023 at 11:14:24AM +0200, Michael wrote:
>> so i looked into /etc/sudoers and all /etc/sudoers.d/* and found two
>> suspicous flags:
>>
>> /etc/sudoers:
>> Defaults       use_pty
>>
>> /etc/sudoers.d/0pwfeedback:
>> Defaults pwfeedback
>>
>> then consulting the sudo manpage convinced me, it was the 'use_pty' flag (in
>> section SUDOERS OPTIONS). after removing that flag everything works as
>> 'expected':
> 
> Well, that is quite the find.  

Indeed! Many thanks Michael.

For background, I followed up some links to get:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657784
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011624
https://bugs.kde.org/show_bug.cgi?id=452532#c28
https://salsa.debian.org/sudo-team/sudo/-/commit/59db341d46aa4c26b54c1270e69f2562e7f3d751

> Given the presence of an /etc/sudoers.dpkg-dist file on my system,
> which does in fact contain this:
> 
> # This fixes CVE-2005-4890 and possibly breaks some versions of kdesu
> # (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)
> Defaults        use_pty
> 
> it looks like you've solved *most* of the mystery.  

But @Greg, if you have "Defaults        use_pty" why haven't you been getting the same instant aborts that I was?

> I still don't get
> why it matters whether the command was executed from bash or dash --

...or ksh or zsh?? Only bash seemed to suffer from having stdin cut off.

Anyway, for my personal purposes, this new behaviour looks too unpredictable and I plan to fall back on capturing stderr in a tempfile. Kludgy but maybe more robust than multiple redirections?

:~$ temp=$(mktemp)
:~$ sudo apt-get install nopkg 2>"$temp"
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
:~$ errors=$(<"$temp")
:~$ echo "$errors"
E: Unable to locate package nopkg
:~$ rm "$temp"

It would be nice to unpick the rest of the mystery though...

(Also, if some day bash had a way of making a variable look like a file for writing.)

-- 
John

[toc] | [prev] | [next] | [standalone]

#261929

On Tue, Sep 26, 2023 at 11:52:09AM +0900, John Crawley wrote:
> On 25/09/2023 20:21, Greg Wooledge wrote:
> > Given the presence of an /etc/sudoers.dpkg-dist file on my system,
> > which does in fact contain this:
> > 
> > # This fixes CVE-2005-4890 and possibly breaks some versions of kdesu
> > # (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)
> > Defaults        use_pty
> > 
> > it looks like you've solved *most* of the mystery.
> 
> But @Greg, if you have "Defaults        use_pty" why haven't you been getting the same instant aborts that I was?

Because it's NOT in /etc/sudoers.  It's in /etc/sudoers.dpkg-dist which
is what WOULD have been installed if I had chosen to overwrite my
existing conffile with the new one.  But I didn't.

[toc] | [prev] | [next] | [standalone]

#261930

On 26/09/2023 12:06, Greg Wooledge wrote:
> On Tue, Sep 26, 2023 at 11:52:09AM +0900, John Crawley wrote:
>> On 25/09/2023 20:21, Greg Wooledge wrote:
>>> Given the presence of an /etc/sudoers.dpkg-dist file on my system,
>>> which does in fact contain this:
>>>
>>> # This fixes CVE-2005-4890 and possibly breaks some versions of kdesu
>>> # (#1011624, https://bugs.kde.org/show_bug.cgi?id=452532)
>>> Defaults        use_pty
>>>
>>> it looks like you've solved *most* of the mystery.
>>
>> But @Greg, if you have "Defaults        use_pty" why haven't you been getting the same instant aborts that I was?
> 
> Because it's NOT in /etc/sudoers.  It's in /etc/sudoers.dpkg-dist which
> is what WOULD have been installed if I had chosen to overwrite my
> existing conffile with the new one.  But I didn't.
> 

Ah OK, I saw  /etc/sudoers.d and carelessly thought of the directory.

-- 
John

[toc] | [prev] | [next] | [standalone]

#265233 — sudo+use_pty+urxvt+pipe [WAS: apt-get aborts in subshell with redirections on Debian 12]

On 26/09/2023 11:52, John Crawley wrote:
> On 25/09/2023 20:21, Greg Wooledge wrote:
>> On Mon, Sep 25, 2023 at 11:14:24AM +0200, Michael wrote:
>>> so i looked into /etc/sudoers and all /etc/sudoers.d/* and found two
>>> suspicous flags:
>>>
>>> /etc/sudoers:
>>> Defaults       use_pty
>>>
>>> /etc/sudoers.d/0pwfeedback:
>>> Defaults pwfeedback
>>>
>>> then consulting the sudo manpage convinced me, it was the 'use_pty' flag (in
>>> section SUDOERS OPTIONS). after removing that flag everything works as
>>> 'expected':
>>
>> Well, that is quite the find. 
> 
> Indeed! Many thanks Michael.
> 
> 8< snip >8
> 
> Anyway, for my personal purposes, this new behaviour looks too unpredictable and I plan to fall back on capturing stderr in a tempfile. Kludgy but maybe more robust than multiple redirections?
> 
> :~$ temp=$(mktemp)
> :~$ sudo apt-get install nopkg 2>"$temp"
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> :~$ errors=$(<"$temp")
> :~$ echo "$errors"
> E: Unable to locate package nopkg
> :~$ rm "$temp"
> 
> It would be nice to unpick the rest of the mystery though...
> 

Revision:
apt commands where STDERR was captured in a variable were (still are) causing the apt prompt to be pre-empted to "No", eg:

(replace mirage with any package which is not installed, and needs to pull in some dependencies, so will call a prompt to confirm)

john@bookworm-tmp:~$ errors=$(sudo apt-get install mirage 2>&1 1>/dev/tty)
[sudo] password for john:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
   gir1.2-gexiv2-0.10 libexiv2-27 libgexiv2-2
Suggested packages:
   exiv2 gimp
The following NEW packages will be installed:
   gir1.2-gexiv2-0.10 libexiv2-27 libgexiv2-2 mirage
0 upgraded, 4 newly installed, 0 to remove and 12 not upgraded.
Need to get 0 B/1,735 kB of archives.
After this operation, 8,373 kB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.

That was because of the new sudo default use_pty, and there seemed to be no workaround, so I switched to sending apt's STDERR to a temporary file instead. Life could go on.

Background:
The function which ran apt was part of a long script which logged all its output to a file for later possible bugfixing, using this line near the beginning:

exec > >( tee -ia "$logfile" ) 2>&1

Once the apt functions no longer used the previous subshell capturing then everything worked fine, until recently, when the aborts reappeared, but only under very specific circumstances, all these:

*) use_pty is set in /etc/sudoers (now default and desirable for security)
*) the apt command is run in a new terminal launched with <terminal> -e bash -c '<command+args>'
*) the terminal is urxvt (I tested xterm, gnome-terminal, lxterminal and terminator - none aborted)
*) the apt command output is either piped (apt install mirage | cat) or redirected to a process substitution (as in the above exec).

Redirecting STDERR to a file (sudo apt-get install mirage 2>"$tempfile") is fine,
and even redirecting STDOUT to a file works (typing blind!).
Redirecting to a command triggers the Abort.

Examples of commands which will cause apt to abort:
urxvt -e bash -c "sudo apt-get install mirage >  >( tee -ia \"$logfile\" )"
urxvt -e bash -c 'sudo apt-get install mirage | cat'
urxvt -e bash -c 'sudo apt-get install mirage | tee /dev/null'
urxvt -e bash -c 'sudo apt-get install mirage >  >( cat )'
urxvt -e bash -c 'sudo apt-get install mirage 2>  >( cat )'

Examples where the Abort is NOT triggered:
urxvt -e bash -c "sudo apt-get install mirage >$filename"
urxvt -e bash -c "sudo apt-get install mirage 2>$filename"
urxvt -e bash -c 'sudo apt-get install mirage 3>  >( cat )'
urxvt -e bash -c "sudo apt-get install mirage 3>  >( tee -ia \"$logfile\" )"
any command where the terminal is not urxvt
any command run directly in the terminal, not in a new one with -e

In fact, to see what's happening in the terminal before it closes, you should append a 'read' command:
urxvt -e bash -c "sudo apt-get install mirage >  >( tee -ia \"$logfile\" ); echo 'Press any key to continue'; read -srn1"

So, is this a urxvt bug, or is it doing the Right Thing here when in a pseudo-terminal and all the others are not?

More practically, is there now any way to record a script's STDOUT to a logfile, while also showing it to the user, while urxvt is set as x-terminal-emulator, if that script is going to run apt commands with sudo?

-- 
John

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web