Bug 114090 - /etc/init.d/stunnel failure (linux-gate.so.1 problem)
Summary: /etc/init.d/stunnel failure (linux-gate.so.1 problem)
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: ConsoleApps (show other bugs)
Version: Beta 3
Hardware: Other All
: P5 - None : Major
Target Milestone: ---
Assignee: Peter Poeml
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 97395
  Show dependency treegraph
 
Reported: 2005-08-30 11:01 UTC by Martin Mrazik
Modified: 2005-09-02 09:35 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mrazik 2005-08-30 11:01:19 UTC
I'm unable to start stunnel configured with imapd:

dhcp44:/etc/ssl/certs # /etc/init.d/stunnel start
Starting stunnel (SSL tunnel) cp: cannot stat `(0xffffe000)': No such file or
directory
.../etc/init.d/stunnel:118: could not copy /usr/sbin/imapd to chroot jfailed
[chroot]               

The bug is int the following code (/etc/init.d/stunnel, line 118):
ldd $i | while read -a line; do
                cp -p ${line[2]} $CHROOT_PREFIX/$libdir \
                    || { echo "...$0:$LINENO: could not copy $i to chroot jail";
rc_failed; rc_status -v1; exit 6; }
            done

The problem is that the code expects output from ldd in the form "library.so =>
path_to_lib.so (0xaddress)", but "ldd impad" shows:

dhcp44:/etc/ssl/certs # ldd /usr/sbin/imapd
        linux-gate.so.1 =>  (0xffffe000)
        libpam.so.0 => /lib/libpam.so.0 (0x4002a000)
...

and since cp is unable to stat "(0xfff...)" (linux-gate.so.1) the script is
unable to continue with copying the libraries to the chroot environment and fails.


PS: I just added the following configuration to the /etc/stunnel/stunnel.conf:
[imaps]
accept = 993
exec = /usr/sbin/imapd
execargs = imapd
pty = no
Comment 1 Peter Poeml 2005-08-30 13:56:18 UTC
will be fixed in 10.0 beta4
Comment 2 Peter Poeml 2005-08-30 13:57:12 UTC
...and, thanks a lot for the report!
Comment 3 Martin Mrazik 2005-09-02 08:12:19 UTC
I'm sorry about this, but this is still unfixed in beta4. It seems that I have
the same version of stunnel on both beta3 and beta4.

dhcp44:~ # rpm -q stunnel
stunnel-4.10-2
Comment 4 Peter Poeml 2005-09-02 09:35:22 UTC
Sorry, I was wrong about the point of time the fix would appear. The
fix was done after Beta4 only. (Checked in today)