Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 141906 - app-shells/bash: interactive bashdb triggered by scripts w/out shebang and w/out --debugger due to `shopt -s extdebug` (openssl/rsstool)
Summary: app-shells/bash: interactive bashdb triggered by scripts w/out shebang and w/...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL: http://lists.gnu.org/archive/html/bug...
Whiteboard:
Keywords:
: 196156 224065 239432 254297 264102 294817 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-07-27 10:40 UTC by Antonio
Modified: 2012-11-05 16:16 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info.txt,2.35 KB, text/plain)
2006-07-30 23:45 UTC, Antonio
Details
emerge-openssl.txt (emerge-openssl.txt,1.93 KB, text/plain)
2006-07-30 23:52 UTC, Antonio
Details
Configure (Configure,87.05 KB, text/plain)
2006-08-01 01:18 UTC, Antonio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio 2006-07-27 10:40:07 UTC
emerge --emptytree failed and now I have broken system.
I tryed 0.9.7j, 0.9.8b. Results are identical.
I tryed to set MAKEOPTS to -j1 and result is the same.

root # emerge -av openssl

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] dev-libs/openssl-0.9.7j  USE="zlib -bindist* -emacs -test" 0 kB 

Total size of downloads: 0 kB

Would you like to merge these packages? [Yes/No] y
>>> Emerging (1 of 1) dev-libs/openssl-0.9.7j to /
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking openssl-0.9.7j.tar.gz ;-)
>>> Unpacking source...
>>> Unpacking openssl-0.9.7j.tar.gz to /var/tmp/portage/openssl-0.9.7j/work
 * Applying openssl-0.9.7g-ppc64.patch ...            [ ok ]
 * Applying openssl-0.9.7e-gentoo.patch ...           [ ok ]
 * Applying openssl-0.9.7-hppa-fix-detection.patch ...[ ok ]
 * Applying openssl-0.9.7-alpha-default-gcc.patch ... [ ok ]
 * Applying openssl-0.9.7g-mem-clr-ptr-cast.patch ... [ ok ]
 * Applying openssl-0.9.7h-ABI-compat.patch ...       [ ok ]
 * Applying openssl-0.9.7g-superh.patch ...           [ ok ]
 * Applying openssl-0.9.7i-m68k.patch ...             [ ok ]
 * Applying openssl-0.9.7g-amd64-fbsd.patch ...       [ ok ]
 * Applying openssl-0.9.7j-doc-updates.patch ...      [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j ...
 * Use configuration linux-pentium
Reading /var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:
[======================>                  ]  56%
done.
(/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1):
1:      :
bashdb<0> quit
Makefile is older than Makefile.org.
Reconfigure the source tree (via './config' or 'perl Configure'), please.
make: *** [Makefile] Error 1

!!! ERROR: dev-libs/openssl-0.9.7j failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  openssl-0.9.7j.ebuild, line 113:   Called die

!!! make all failed
!!! If you need support, post the topmost build error, and the call stack if
relevant.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-07-27 10:59:24 UTC
Uhm, fix your system clock?
Comment 2 Antonio 2006-07-27 11:15:08 UTC
It seems to be (In reply to comment #1)
> Uhm, fix your system clock?
> 

It seems to be fine
antonio ~ $ date
Thu Jul 27 21:03:38 EEST 2006

Make file really was not touched (I checked it manually)
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-07-27 11:18:45 UTC
bug-wranglers@gentoo.org
Comment 4 Antonio 2006-07-28 12:16:52 UTC
(In reply to comment #3)
> bug-wranglers@gentoo.org
> 

Sorry, I do not understand.
Comment 5 SpanKY gentoo-dev 2006-07-30 16:47:12 UTC
you forgot `emerge info`

do you use tmpfs or anything for your portage tempdir ?

also, post the full log as an attachment, not just a snippet:
emerge openssl >& log
Comment 6 Antonio 2006-07-30 23:45:48 UTC
Created attachment 93104 [details]
emerge --info
Comment 7 Antonio 2006-07-30 23:51:29 UTC
(In reply to comment #5)
> you forgot `emerge info`
> 
Sorry :)

> do you use tmpfs or anything for your portage tempdir ?
> 
antonio ~ $ mount
/dev/sda6 on / type reiserfs (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
udev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw)
/dev/sda7 on /var type reiserfs (rw,noatime)
/dev/sda8 on /tmp type reiserfs (rw,noatime,notail)
/dev/sda9 on /home type reiserfs (rw)
none on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw,devmode=0664,devgid=85)
avfsd on /home/antonio/.avfs type fuse (rw,nosuid,nodev,user=antonio)

> also, post the full log as an attachment, not just a snippet:
> emerge openssl >& log
> 

antonio # emerge -v openssl >& emerge-openssl.txt
Reading /var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure: [======================>                  ]  56%
done.
(/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1):
1:      :
bashdb<0> quit

I attached file emerge-openssl.txt
Comment 8 Antonio 2006-07-30 23:52:23 UTC
Created attachment 93105 [details]
emerge-openssl.txt
Comment 9 SpanKY gentoo-dev 2006-07-31 20:53:15 UTC
you have something screwing up your bash:

done.
(/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1):
1:      :
bashdb<0> quit
Comment 10 Antonio 2006-08-01 07:11:31 UTC
(In reply to comment #9)
> you have something screwing up your bash:
> 
> done.
> (/var/tmp/portage/openssl-0.9.7j/work/openssl-0.9.7j/Configure:1):
> 1:      :
> bashdb<0> quit
> 

You are right :)

But my bash is ok. I attached Configure script. It contains some garbage in the beginning. It seems to me that this script was not generated correctly.
Comment 11 SpanKY gentoo-dev 2006-08-02 21:01:03 UTC
the Configure script is not generated, it's part of the tarball
Comment 12 Antonio 2006-08-20 06:10:23 UTC
Sorry for a long break. I was on vacation.

You are right: Configure is a part of source tarball. Here is the beginning of this script:

:
eval 'exec perl -S $0 ${1+"$@"}'
    if $running_under_some_shell;
##
##  Configure -- OpenSSL source tree configuration script
##

... and so on ...

than I see to ebuild:

... <skip> ...
src_compile() {
	... <skip> ...
	local sslout=$(./gentoo.config)
	einfo "Use configuration ${sslout}"

	local config="Configure"
	[[ -z ${sslout} ]] && config="config"
	./${config} \
		${sslout} \
		${confopts} \
		--prefix=/usr \
		--openssldir=/etc/ssl \
		shared threads \
		|| die "Configure failed"
... <skip> ...

I mean that ebuild executes perl script as bash script.

IMHO this behaviour is unexpected because if I run gentoo.config from comand prompt it outputs nothing. But when emerge runs it, gentoo.config outputs linux-pentium. This is why I think that ebuild contains a bug.

Comment 13 SpanKY gentoo-dev 2006-08-20 14:06:35 UTC
yes, the script is funky, but it is correct

the reason ./gentoo.config outputs stuff in the ebuild is it uses the CHOST env

i'm telling you your bash is screwed up and you need to figure out why ... i dont know what this 'bashdb' stuff is, but it's a local problem on your machine
Comment 14 SpanKY gentoo-dev 2007-12-24 13:28:18 UTC
*** Bug 196156 has been marked as a duplicate of this bug. ***
Comment 15 Evgeny Stambulchik 2007-12-25 10:19:15 UTC
(In reply to comment #13)

> i'm telling you your bash is screwed up and you need to figure out why ... i
> dont know what this 'bashdb' stuff is, but it's a local problem on your machine

Do `strings /bin/bash |grep bashdb' and you'll see _your_ machine knows about it something, too ;-)

OK, so there are several bugs/problems:

1a. The bash ebuild is wrong, pointing to /usr/local/share/bashdb/bashdb-main.inc for the debugging stuff.

1b. The support for bash debugging is broken, since /usr/share/bashdb/* is not installed.

2. On my system (and apparently, on Antonio's), a standalone bashdb script (together with the /usr/local/share/bashdb/* files) was installed, which enabled the debugging support.

3. Portage (specifically, ebuild.sh) enables the debugging:

$ grep extdebug /usr/lib/portage/bin/ebuild.sh 
shopt -s extdebug &> /dev/null

No idea why the hell it's doing so (especially since, due to (1b), it wouldn't work on a pure Gentoo system); commenting it out lets the openssl ebuild proceed nicely here.

4. The openssl "Configure" script is broken. It's actually a perl script, but the perl interpreter is invoked in a non-standard way, trap'ping bash to the debug prompt. I don't understand what's wrong with the recommended by perldoc #!/usr/bin/env perl ???

Mind you, (1a), especially together with (3), makes a security issue, since files under /usr/local are typically paid less security attention to.
Comment 16 SpanKY gentoo-dev 2007-12-27 19:45:50 UTC
there is no security issue.  if your system has problems with /usr/local, it's already screwed.  blaming others for admin incompetence is incorrect.  might as well claim /usr/local/bin being in default PATH is a security issue (spoiler alert: it isnt).

if you read the man page for bash, you'll see clearly why the extdebug shell option is turned on and why it's a good thing.

the openssl Configure script is not broken.  it may be weird, sure, but it is perfectly valid.

the bash ebuild does not do anything about bashdb.  that is why the default bash configure script selects /usr/local/...  i'll fix that.

bash is not broken by not installing the bashdb stuff.  bash itself includes no bashdb that is meant to be used as you're supposed to use bashdb.sf.net instead.  optionally.

tar the files you have in /usr/local/share/bashdb/ and post it as an attachment
Comment 17 Evgeny Stambulchik 2007-12-27 20:43:22 UTC
(In reply to comment #16)
> there is no security issue.  if your system has problems with /usr/local, it's
> already screwed.

If nothing is screwed for sure, things like firewall are not needed. I have a couple systems with / and /usr mounted RO, while /usr/local - not. So an idea that emerge, running as the root user, may run something off /usr/local behind my back is not especially exciting. 

> blaming others for admin incompetence is incorrect.  might as
> well claim /usr/local/bin being in default PATH is a security issue (spoiler
> alert: it isnt).

I don't mind default settings. PATH is something which each one can define to his pleasure (and indeed, restricting it to /*bin/ and /usr/*bin/ for the root user is not unseen in the wild). However, when /usr/local/bin is forcefully added by a system-level script (emerge), this is an issue - so why it's there?!

> if you read the man page for bash, you'll see clearly why the extdebug shell
> option is turned on and why it's a good thing.

I don't see which place in the bash man page you refer to. Please specify. All I can tell, however, it is OFF by default - on all Linux distributions I have access to:

$ shopt extdebug
extdebug        off

Again, it is ebuild.sh that sets it ON - and for no apparent reason.

> the openssl Configure script is not broken.  it may be weird, sure, but it is
> perfectly valid.

The fact is it's single one (out of thousands of other ebuilds) which causes this problem. Changing the perl invocation to #!/usr/bin/env perl fixes the problem. Do you have an explanation why the way it's done is needed?

> the bash ebuild does not do anything about bashdb.  that is why the default
> bash configure script selects /usr/local/...  i'll fix that.
> 
> bash is not broken by not installing the bashdb stuff.  bash itself includes no
> bashdb that is meant to be used

You're right. I stand corrected.

> as you're supposed to use bashdb.sf.net
> instead.  optionally.

Well, a bashdb ebuild (putting stuff under /usr/, of course) might be a good thing to add then. I recall installing bashdb manually because portage didn't have one...

> tar the files you have in /usr/local/share/bashdb/ and post it as an attachment

Hmm. Do you say if you install from bashdb.sf.net you cannot reproduce the bug?!
Comment 18 SpanKY gentoo-dev 2007-12-27 21:19:49 UTC
we're not talking about the default bash environment, so the settings there are not relevant.  turning it on inside of the ebuild environment is needed even if it isnt apparent to you.  read the section about what extdebug actually turns on under the shopt section and you'll see that the ebuild code takes advantage of the extra information that bash tracks.

while on Gentoo systems env lives at /usr/bin/env, there is no requirement that every single system out there be this way.  openssl is a cross-platform system and the people who wrote the build system deemed that the current trick of letting the active shell find perl via $PATH is more portable.  personally i think using perl in a build system at all is stupid.  perl blows.

i just made a bashdb ebuild and added it to the tree and can reproduce the failure here.  not sure why it's failing as the debug stuff should be be inherited by children processes, only subshells.  this will fail as well:
echo ':' > foo
chmod a+rx foo
./foo
Comment 19 SpanKY gentoo-dev 2007-12-27 21:20:50 UTC
erm, that last statement should of course read "should not be inherited" ...
Comment 20 Evgeny Stambulchik 2007-12-27 22:02:10 UTC
(In reply to comment #18)
> turning it on inside of the ebuild environment is needed even if
> it isnt apparent to you.

I'll take your word for it ;-). Still, the other shopt call in ebuild.sh is documented, so this might be as well. My initial understanding was that all the debugging stuff is enabled only if the bashdb support files are in the place.

> while on Gentoo systems env lives at /usr/bin/env, there is no requirement that
> every single system out there be this way.  openssl is a cross-platform system
> and the people who wrote the build system deemed that the current trick of
> letting the active shell find perl via $PATH is more portable.

Perhaps. But why not patch it in the Gentoo ebuild? - given that extdebug is important for portage, is there another solution?

> personally i
> think using perl in a build system at all is stupid.

Agreed ;-).

> i just made a bashdb ebuild and added it to the tree

Thanks!

> and can reproduce the
> failure here.  not sure why it's failing as the debug stuff should not be
> inherited by children processes, only subshells.  this will fail as well:
> echo ':' > foo
> chmod a+rx foo
> ./foo

Well, isn't it the point - since the script does NOT begin with #!/bin/bash (or any other interpreter), it inherits the flag.
Comment 21 SpanKY gentoo-dev 2008-06-21 15:05:28 UTC
needs some more fiddling
Comment 22 SpanKY gentoo-dev 2008-06-21 15:05:35 UTC
*** Bug 224065 has been marked as a duplicate of this bug. ***
Comment 23 Julien 2008-08-06 09:45:53 UTC
Arg i spend hours on a so old bug!

On my system Configure just warn with a message like "can't open /dev/pty/8", openssl compiles, but install mess with directory (because of Configure) and crashes with:
"cd: /var/tmp/portage/dev-libs/openssl-0.9.8g-r2/image//usr/share/man: no such file or directory"

Is it possible to add at least a warning if bashdb is installed:
"You should first unmerge bashdb before updating openssl" ???
Comment 24 Ricky C 2008-08-13 03:34:36 UTC
(In reply to comment #23)
> Is it possible to add at least a warning if bashdb is installed:
> "You should first unmerge bashdb before updating openssl" ???
> 

That would be nice.  I unmerged bashdb and the problem went away and I could continue with my update of world...

This was with openssl-0.9.7g

Ricky
Comment 25 Jeroen Roovers gentoo-dev 2009-01-13 16:14:54 UTC
*** Bug 254297 has been marked as a duplicate of this bug. ***
Comment 26 Shaun Attfield 2009-01-17 02:30:42 UTC
Problem still persists with openssl-0.9.8j and bashdb-4.0.0.2 on ~amd64.
Unmerging bashdb allows openssl to emerge.

Is this an issue with openssl or with bashdb? How can this issue be fixed?
Only openssl exhibits this problem, so I am inclined to blame openssl, but then the question of whether this a Gentoo-only issue arises.
Google implies Gentoo-only.

Unfortunately openssl is updated fairly often, so unmerging bashdb each time is a bit painful.
Comment 27 SpanKY gentoo-dev 2009-03-29 01:03:52 UTC
*** Bug 264102 has been marked as a duplicate of this bug. ***
Comment 28 Roger 2009-10-24 07:39:53 UTC
=dev-scheme/slib-3.1.5-r1 seems to be triggering this as well.

I think I reproduced it twice here.

>>> Installing (57 of 1788) dev-scheme/slib-3.1.5-r1
 * bigloo not installed, not registering...
 * drscheme not installed, not registering...
 * elk not installed, not registering...
 * gambit not installed, not registering...
 * Registering slib with guile...
 debugger, release

Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Bourne-Again Shell Debugger, release

Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

 debugger, release

Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(/usr/sbin/install_slib_for_guile:1):
1:      guile -c "(use-modules (ice-9 slib)) (require 'new-catalog) (slib:report-version)"
bashdb<(0)>
bashdb<(1)>
bashdb<(2)>
bashdb<(3)>
bashdb<(4)>
bashdb<(5)>
bashdb<(6)>
bashdb<(7)>
bashdb<(8)>
bashdb<(9)>
bashdb<(10)>
bashdb<(11)>

emerge -C app-shells/bashdb(-4.0.0.3) allows emerging slib without interaction.
Comment 29 SpanKY gentoo-dev 2009-10-24 09:03:36 UTC
then file a bug for dev-scheme/slib to have it use a proper shebang
Comment 30 SpanKY gentoo-dev 2010-01-11 03:36:14 UTC
*** Bug 239432 has been marked as a duplicate of this bug. ***
Comment 31 SpanKY gentoo-dev 2010-01-24 19:11:13 UTC
*** Bug 294817 has been marked as a duplicate of this bug. ***