[Bugs] [Bug 1618838] New: gluster bash completion leaks TOP= 0 into the environment

bugzilla at redhat.com bugzilla at redhat.com
Fri Aug 17 18:26:05 UTC 2018


https://bugzilla.redhat.com/show_bug.cgi?id=1618838

            Bug ID: 1618838
           Summary: gluster bash completion leaks TOP=0 into the
                    environment
           Product: GlusterFS
           Version: 3.12
         Component: scripts
          Keywords: Triaged
          Severity: medium
          Priority: medium
          Assignee: bugs at gluster.org
          Reporter: anoopcs at redhat.com
                CC: anoopcs at redhat.com, bugs at gluster.org,
                    humble.devassy at gmail.com, joe at julianfamily.org,
                    jonathansteffan at gmail.com, lmohanty at redhat.com,
                    mark at mark.mielke.cc, mmielke at ciena.com,
                    ndevos at redhat.com, ramkrsna at gmail.com,
                    rjones at redhat.com, thomas.jarosch at intra2net.com
        Depends On: 1425325
            Blocks: 1425326, 1360888



+++ This bug was initially created as a clone of Bug #1425325 +++

+++ This bug was initially created as a clone of Bug #1360888 +++

Description of problem:

On my machine I have a bash shell variable called "TOP" defined:

$ echo $TOP
0

(Note this is not an environment variable).  This breaks
various things, in this case the lowRISC initialization script.

The variable comes from gluster bash completion script
/etc/bash_completion.d/gluster

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

glusterfs-cli-3.8.0-0.2.rc2.fc24.x86_64

How reproducible:

100%

Steps to Reproduce:
1. echo $TOP

--- Additional comment from Niels de Vos on 2016-09-12 07:37:16 CEST ---

All 3.8.x bugs are now reported against version 3.8 (without .x). For more
information, see
http://www.gluster.org/pipermail/gluster-devel/2016-September/050859.html

--- Additional comment from Anoop C S on 2017-02-21 07:16:52 CET ---

(In reply to Richard W.M. Jones from comment #0)
> Description of problem:
> 
> On my machine I have a bash shell variable called "TOP" defined:
> 
> $ echo $TOP
> 0
> 
> (Note this is not an environment variable).  This breaks
> various things, in this case the lowRISC initialization script.
> 

Can you please direct towards this initialization script?

And how severe is the issue?

> The variable comes from gluster bash completion script
> /etc/bash_completion.d/gluster
> 
> Version-Release number of selected component (if applicable):
> 
> glusterfs-cli-3.8.0-0.2.rc2.fc24.x86_64
> 
> How reproducible:
> 
> 100%
> 
> Steps to Reproduce:
> 1. echo $TOP

--- Additional comment from Richard W.M. Jones on 2017-02-21 09:26:22 CET ---

(In reply to Anoop C S from comment #2)
> Can you please direct towards this initialization script?

As stated in the original description:

  /etc/bash_completion.d/gluster

from the package glusterfs-cli.  In the source, this file is
called extras/command-completion/gluster.bash

> And how severe is the issue?

Annoying more than severe.  However it prevents building all
the RISC-V upstream software.

--- Additional comment from Niels de Vos on 2017-02-21 09:37:39 CET ---

It looks like "TOP" is not the only variable that leaks:

>From <glusterfs.git>/extras/command-completion/gluster.bash:
285 declare FINAL_LIST=''
286 declare LIST=''
287 declare -i TOP=0

--- Additional comment from Anoop C S on 2017-08-23 12:39:47 IST ---

> It looks like "TOP" is not the only variable that leaks:
> 
> From <glusterfs.git>/extras/command-completion/gluster.bash:
> 285 declare FINAL_LIST=''
> 286 declare LIST=''
> 287 declare -i TOP=0

What are the different ways in which such variables can be leaked into main
script? One way that I can think of is by sourcing the child script(in this
case gluster.bash) into main script(whatever it is). Otherwise these variables
won't leak to outside world as they are used inside subshell.

Please feel free to correct me if I am wrong.

@Richard,
Are you sourcing the gluster bash completion script into your specific script?

--- Additional comment from Richard W.M. Jones on 2017-08-23 15:29:34 IST ---

Of course not.

Simply starting a new shell shows that $TOP is defined:

$ echo $TOP 
0

--- Additional comment from Anoop C S on 2017-08-24 17:03:09 IST ---

(In reply to Richard W.M. Jones from comment #2)
> Of course not.
> 
> Simply starting a new shell shows that $TOP is defined:
> 
> $ echo $TOP 
> 0

Ok.

So these bash completion scripts are being sourced and is available at launch
of each session. It's the case that some other bash completion script are also
leaking variables to outside world. Every session launch sources bash
completion scripts from /etc/bash_completion.d/ via
/usr/share/bash-completion/bash_completion[1] which in turn is sourced from
/etc/profile.d/bash_completion[2] profile script.

[1] https://github.com/scop/bash-completion/blob/master/bash_completion#L2070
[2]
https://github.com/scop/bash-completion/blob/master/bash_completion.sh.in#L11

So.. now to /etc/bash_completion.d/gluster, I guess we need to make all those
kind of global variables local to its completion script by rearranging the
whole logic.

--- Additional comment from Thomas Jarosch on 2017-10-24 01:47:59 IST ---

Compiling LineageOS / Android was no longer possible after updating from F25 to
F26.

export TOP=/mnt/android/lineageos

resulted in

-bash: export: /mnt/android/lineageos/: syntax error: operand expected (error
token is "/mnt/android/lineageos/)


-> removing /etc/bash_completion.d/gluster solved the issue.

Still I wish I spent debugging 30 minutes somewhere else :D

--- Additional comment from Mark Mielke on 2018-08-02 14:49:58 IST ---

We're hitting this as well:

-bash-4.2$ cat /etc/system-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
-bash-4.2$ rpm -q glusterfs-cli
glusterfs-cli-3.7.1-16.el7.x86_64
-bash-4.2$ TOP=/abc
-bash: /abc: syntax error: operand expected (error token is "/abc")
-bash-4.2$ grep "declare -i" /etc/bash_completion.d/gluster 
declare -i TOP=0
-bash-4.2$ declare +i TOP
-bash-4.2$ TOP=/abc
-bash-4.2$ 

It's not just that it is leaked, but that it is declared with "+i" causing bash
to interpret it in an integer context from the on.

This needs to be fixed. We have build scripts that set TOP=/path and users
upgrading from RHEL 6 to RHEL 7 are hitting this problem now.

Remove glusterfs-cli doesn't seem to be a good option either as even though we
don't really use gluster, we do use libvirt, and libvirt ends up pulling in
glusterfs-cli.

--- Additional comment from Mark Mielke on 2018-08-14 09:57:17 IST ---

I opened this change request upstream on master:

https://review.gluster.org/#/c/glusterfs/+/20732/

Once approved, I will pursue requesting that it be backported into RHEL 7. This
may mean backport to 3.8 (used by RHEL 7.5), or 3.12 (used by future RHEL 7.x
release?).

Although I mention 3.7 above, I would be happy just to get it in RHEL 7.5 or
7.6. For prior releases, we'll come up with our own work-around.

--- Additional comment from Worker Ant on 2018-08-14 10:01:27 IST ---

REVIEW: https://review.gluster.org/20732 (Fix Bash command completion script to
namespace global variables.) posted (#3) for review on master by

--- Additional comment from Richard W.M. Jones on 2018-08-14 13:11:44 IST ---

The patch looks good, thanks for dealing with this.  Once it goes
upstream it should easy to get it into RHEL >= 7.7, and less
easy for older RHEL 7.

--- Additional comment from Worker Ant on 2018-08-17 11:02:56 IST ---

REVISION POSTED: https://review.gluster.org/20752 (Bash integration script
should namespace variables) posted (#2) for review on release-4.1 by Anoop C S


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1360888
[Bug 1360888] gluster bash completion leaks TOP=0 into the environment
https://bugzilla.redhat.com/show_bug.cgi?id=1425325
[Bug 1425325] gluster bash completion leaks TOP=0 into the environment
https://bugzilla.redhat.com/show_bug.cgi?id=1425326
[Bug 1425326] gluster bash completion leaks TOP=0 into the environment
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list