RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2097625 - heredoc lines get consumed by previous statement
Summary: heredoc lines get consumed by previous statement
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: bash
Version: 8.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Siteshwar Vashisht
QA Contact: Karel Volný
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-16 07:43 UTC by Renaud Métrich
Modified: 2023-03-24 09:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-03-24 09:15:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenSSH Project 3448 0 None None None 2022-06-17 09:26:07 UTC
Red Hat Issue Tracker CRYPTO-7623 0 None None None 2022-06-21 14:46:24 UTC
Red Hat Issue Tracker RHELPLAN-125427 0 None None None 2022-06-16 07:45:34 UTC

Description Renaud Métrich 2022-06-16 07:43:07 UTC
Description of problem:

I don't know if the issue is with bash or sshd, but I believe it's more sshd since the same can be reproduced with zsh but not ksh.
When having a HEREDOC processed through ssh, it appears that any stdin consumer will "eat" the next lines in HEREDOC instead of reading on standard input, as shown in the example below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ ssh -t -t localhost << EOF
tty
cat
echo HELLO
EOF

tty
cat
echo HELLO
[root@vm-rhel8 ~]# tty
/dev/pts/1
[root@vm-rhel8 ~]# cat
echo HELLO
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

On RHEL7, we have the "cat" command wait for input, whereas on RHEL8 and RHEL9, we have the "cat" command read next line ("echo HELLO") then wait for input.
The same is reproducible with zsh, but not ksh:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ ssh -t -t localhost ksh << EOF
tty
cat
echo HELLO
EOF
tty
cat
echo HELLO
# 
/dev/pts/1
#
---> this is "cat" execution waiting on standard input. "echo HELLO" was not processed yet.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Version-Release number of selected component (if applicable):

openssh-server-8.0p1-13.el8.x86_64

How reproducible:

Always

Steps to Reproduce: see above

Actual results:

"echo HELLO" being processed by "cat"

Expected results:

"cat" just waiting for input

Additional info:

There is a real issue behind this. As soon as a program "eats" stdin, such as "systemctl" commands, weird behaviour happens, as shown below:

- On RHEL7, no issue

Command:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# ssh -t -t vm-rhel7 << EOF
systemctl status sshd
echo "RC $?"
exit
EOF

systemctl status sshd
echo "RC 0"
exit
Last login: Thu Jun 16 09:39:32 2022 from localhost
[root@vm-rhel7 ~]# systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-06-16 08:55:23 CEST; 46min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1044 (sshd)
    Tasks: 1
   Memory: 5.7M
   CGroup: /system.slice/sshd.service
           └─1044 /usr/sbin/sshd -D

Jun 16 09:33:08 vm-rhel7 sshd[4279]: Accepted publickey for root from ::1 p...E4
Jun 16 09:33:19 vm-rhel7 sshd[4366]: Accepted publickey for root from ::1 p...E4
Jun 16 09:33:53 vm-rhel7 sshd[4473]: Accepted publickey for root from ::1 p...E4
Jun 16 09:34:19 vm-rhel7 sshd[4602]: Accepted publickey for root from ::1 p...E4
Jun 16 09:35:19 vm-rhel7 sshd[4767]: Accepted publickey for root from ::1 p...E4
Jun 16 09:35:30 vm-rhel7 sshd[4853]: Accepted publickey for root from ::1 p...E4
Jun 16 09:36:14 vm-rhel7 sshd[4987]: Accepted publickey for root from ::1 p...E4
Jun 16 09:39:08 vm-rhel7 sshd[5363]: Accepted publickey for root from ::1 p...E4
Jun 16 09:39:32 vm-rhel7 sshd[5485]: Accepted publickey for root from ::1 p...E4
Jun 16 09:41:33 vm-rhel7 sshd[5699]: Accepted publickey for root from 192.1...E4
Hint: Some lines were ellipsized, use -l to show in full.
[root@vm-rhel7 ~]# echo "RC 0"
RC 0
[root@vm-rhel7 ~]# exit
logout
Connection to vm-rhel7 closed.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

- On RHEL8, breaks due to pager (started by "systemctl status") eating "echo "RC $?"" line
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# ssh -t -t vm-rhel8 << EOF
systemctl status sshd
echo "RC $?"
exit
EOF

systemctl status sshd
echo "RC 0"
exit
[root@vm-rhel8 ~]# systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset>
   Active: active (running) since Thu 2022-06-16 08:53:15 CEST; 48min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 896 (sshd)
    Tasks: 1 (limit: 11377)
   Memory: 9.5M
   CGroup: /system.slice/sshd.service
           └─896 /usr/sbin/sshd -D -oCiphers=aes256-gcm,chacha20-po>

Jun 16 09:36:25 vm-rhel8 sshd[2832]: pam_unix(sshd:session): session opened for>
Jun 16 09:36:41 vm-rhel8 sshd[2895]: Accepted publickey for root from 192.168.1>
Jun 16 09:36:41 vm-rhel8 sshd[2895]: pam_unix(sshd:session): session opened for>
Jun 16 09:39:19 vm-rhel8 sshd[2958]: Accepted publickey for root from 192.168.1>
Jun 16 09:39:19 vm-rhel8 sshd[2958]: pam_unix(sshd:session): session opened for>
Jun 16 09:39:19 vm-rhel8 sshd[2958]: pam_unix(sshd:session): session closed for>
Jun 16 09:39:39 vm-rhel8 sshd[3026]: Accepted publickey for root from 192.168.1>
Jun 16 09:39:39 vm-rhel8 sshd[3026]: pam_unix(sshd:session): session opened for>
Jun 16 09:41:55 vm-rhel8 sshd[3078]: Accepted publickey for root from 192.168.1>
Jun 16 09:41:55 vm-rhel8 sshd[3078]: pam_unix(sshd:session): session opened for>
...skipping...

                   SUMMARY OF LESS COMMANDS

      Commands marked with * may be preceded by a number, N.
      Notes in parentheses indicate the behavior if N is given.
      A key preceded by a caret indicates the Ctrl key; thus ^K is ctrl-K.
...
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Comment 4 Renaud Métrich 2022-06-17 08:35:22 UTC
Hi Dmitry, I will file it as soon as you confirm there is something wrong here compared to RHEL7.

Comment 5 Dmitry Belyavskiy 2022-06-17 08:42:09 UTC
Dear Renaud,

It definitely looks weird to me. And the difference between OpenSSH in RHEL 7 and RHEL 8 is rather big

Comment 6 Dmitry Belyavskiy 2022-06-24 08:47:09 UTC
https://bugzilla.mindrot.org/show_bug.cgi?id=3448#c1 is the upstream position, so probably it's worth considering to change the component.

Comment 7 Dmitry Belyavskiy 2022-09-08 12:37:25 UTC
Changing the component according to comment #6


Note You need to log in before you can comment on or make changes to this bug.