Bug 1425325
| Summary: | gluster bash completion leaks TOP=0 into the environment | |||
|---|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Niels de Vos <ndevos> | |
| Component: | scripts | Assignee: | Mark Mielke <mmielke> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ||
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | mainline | CC: | anoopcs, bugs, humble.devassy, joe, jonathansteffan, lmohanty, mark, mmielke, ndevos, ramkrsna, rjones, thomas.jarosch | |
| Target Milestone: | --- | Keywords: | Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | glusterfs-5.0 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | 1360888 | |||
| : | 1425326 1618838 (view as bug list) | Environment: | ||
| Last Closed: | 2018-09-19 06:55:44 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1360888, 1425326, 1618838 | |||
|
Description
Niels de Vos
2017-02-21 08:38:29 UTC
> 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?
Of course not. Simply starting a new shell shows that $TOP is defined: $ echo $TOP 0 (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. 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 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. 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. REVIEW: https://review.gluster.org/20732 (Fix Bash command completion script to namespace global variables.) posted (#3) for review on master by 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. 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 This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report. glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html [2] https://www.gluster.org/pipermail/gluster-users/ |