Bug 842 - ldd tries to start xterm!
: ldd tries to start xterm!
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/glibc-utils)
: unstable
: all Linux
: P4 major
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2002-04-14 16:36 by
Modified: 2003-08-25 15:18 (History)


Attachments


Note

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


Description From 2002-04-14 16:36:50
running ldd $(which xterm) causes an attempt to connect to X server. See below
for more details.
---
# ldd on gnome-terminal is fine, but on xterm it is not:

[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]# ldd
/usr/bin/gnome-terminal 
    libglade-gnome.so.0 =&gt; /usr/lib/libglade-gnome.so.0 (0x40021000)
    libm.so.6 =&gt; /lib/libm.so.6 (0x40030000)
    libz.so.1 =&gt; /lib/libz.so.1 (0x40053000)
    libglade.so.0 =&gt; /usr/lib/libglade.so.0 (0x40062000)
    libxml.so.1 =&gt; /usr/lib/libxml.so.1 (0x4007b000)
    libzvt.so.2 =&gt; /usr/lib/libzvt.so.2 (0x400ee000)
    libutil.so.1 =&gt; /lib/libutil.so.1 (0x40103000)
    libgnorba.so.27 =&gt; /usr/lib/libgnorba.so.27 (0x40106000)
    libORBitCosNaming.so.0 =&gt; /usr/lib/libORBitCosNaming.so.0 (0x40112000)
    libORBit.so.0 =&gt; /usr/lib/libORBit.so.0 (0x4011a000)
    libIIOP.so.0 =&gt; /usr/lib/libIIOP.so.0 (0x40154000)
    libORBitutil.so.0 =&gt; /usr/lib/libORBitutil.so.0 (0x4015b000)
    libgnomeui.so.32 =&gt; /usr/lib/libgnomeui.so.32 (0x4015d000)
    libart_lgpl.so.2 =&gt; /usr/lib/libart_lgpl.so.2 (0x4022f000)
    libgdk_imlib.so.1 =&gt; /usr/lib/libgdk_imlib.so.1 (0x4023e000)
    libSM.so.6 =&gt; /usr/X11R6/lib/libSM.so.6 (0x40261000)
    libICE.so.6 =&gt; /usr/X11R6/lib/libICE.so.6 (0x40269000)
    libgtk-1.2.so.0 =&gt; /usr/lib/libgtk-1.2.so.0 (0x40281000)
    libgdk-1.2.so.0 =&gt; /usr/lib/libgdk-1.2.so.0 (0x403af000)
    libgmodule-1.2.so.0 =&gt; /lib/libgmodule-1.2.so.0 (0x403e4000)
    libdl.so.2 =&gt; /lib/libdl.so.2 (0x403e7000)
    libXi.so.6 =&gt; /usr/X11R6/lib/libXi.so.6 (0x403ea000)
    libXext.so.6 =&gt; /usr/X11R6/lib/libXext.so.6 (0x403f2000)
    libX11.so.6 =&gt; /usr/X11R6/lib/libX11.so.6 (0x403ff000)
    libgnome.so.32 =&gt; /usr/lib/libgnome.so.32 (0x404dd000)
    libgnomesupport.so.0 =&gt; /usr/lib/libgnomesupport.so.0 (0x404f5000)
    libesd.so.0 =&gt; /usr/lib/libesd.so.0 (0x404fa000)
    libaudiofile.so.0 =&gt; /usr/lib/libaudiofile.so.0 (0x40502000)
    libdb.so.2 =&gt; /lib/libdb.so.2 (0x40524000)
    libglib-1.2.so.0 =&gt; /lib/libglib-1.2.so.0 (0x40532000)
    libc.so.6 =&gt; /lib/libc.so.6 (0x40557000)
    /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]# ldd
/usr/X11R6/bin/xterm 
X connection to localhost:11.0 broken (explicit kill or server shutdown).
[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]# rpm -qf
/usr/X11R6/bin/xterm /usr/bin/gnome-terminal $(which ldd)
xterm-166-alt1
gnome-core-1.4.0.4-alt6
glibc-utils-2.2.5-alt3
[<a href="mailto:root@shamrock" target="_new">root@shamrock</a> root]#

---
------- Comment #1 From 2002-04-14 17:08:44 -------
And if the DISPLAY is accessible for connection, ldd $(which xterm) run as root
really starts an xterm and does not print the list of library links.
------- Comment #2 From 2002-04-14 17:08:44 -------
And if the DISPLAY is accessible for connection, ldd $(which xterm) run as root
really starts an xterm and does not print the list of library links.
------- Comment #3 From 2002-04-15 12:14:03 -------
glibc dynamic linker doesn\'t allow to trace SUID/SGID applications.
------- Comment #4 From 2002-04-15 12:14:03 -------
glibc dynamic linker doesn\'t allow to trace SUID/SGID applications.
------- Comment #5 From 2002-05-15 13:43:12 -------
Running a file is an unexpected, undesirable and undocumented effect.
Should it be considered as a bug?
------- Comment #6 From 2002-05-15 13:43:12 -------
Running a file is an unexpected, undesirable and undocumented effect.
Should it be considered as a bug?
------- Comment #7 From 2002-05-15 13:53:52 -------
Nope, this is not a bug - it\'s a glibc dynamic linker security featute.
It\'s should be documented somewhere... where?
------- Comment #8 From 2002-05-15 13:53:52 -------
Nope, this is not a bug - it\'s a glibc dynamic linker security featute.
It\'s should be documented somewhere... where?
------- Comment #9 From 2002-05-15 20:59:37 -------
I thought this issue over once more, and now I\'d insist that this is not the
right way for ldd to behave. It is very dangerous, and merely documenting this
will not be enough. IMHO ldd should not start any program if it can\'t trace
it, and print out some error message instead.

Consider a program like this:

main() {
  execlp(\&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}

Its binary (./rmall) is set setUID root (why? it\'s not important).
A user may be clever enough not to run ./rmall, but he may be interested in the
output of ldd ./rmall. So he runs

ldd ./rmall

and something awful and completely unexpected happens: ldd runs it, and what is
worse, it is run with root\'s permissions. And the user just wanted to know how
it is linked, he assumed that ldd is an innocent program for exploring other
programs.
------- Comment #10 From 2002-05-15 20:59:37 -------
I thought this issue over once more, and now I\'d insist that this is not the
right way for ldd to behave. It is very dangerous, and merely documenting this
will not be enough. IMHO ldd should not start any program if it can\'t trace
it, and print out some error message instead.

Consider a program like this:

main() {
  execlp(\&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}

Its binary (./rmall) is set setUID root (why? it\'s not important).
A user may be clever enough not to run ./rmall, but he may be interested in the
output of ldd ./rmall. So he runs

ldd ./rmall

and something awful and completely unexpected happens: ldd runs it, and what is
worse, it is run with root\'s permissions. And the user just wanted to know how
it is linked, he assumed that ldd is an innocent program for exploring other
programs.
------- Comment #11 From 2002-05-16 08:31:47 -------
small fix to the previous note to be correct:

main() {
execlp(\&quot;/bin/rm\&quot;, \&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}
------- Comment #12 From 2002-05-16 08:31:47 -------
small fix to the previous note to be correct:

main() {
execlp(\&quot;/bin/rm\&quot;, \&quot;/bin/rm\&quot;, \&quot;-rf\&quot;, \&quot;/\&quot;, 0);
}
------- Comment #13 From 2002-05-16 13:21:00 -------
I have to agree; ldd should either
+ trace dynamic linker as expected;
or
+ exit with EPERM.

I have an idea how to fix it.
------- Comment #14 From 2002-05-16 13:21:00 -------
I have to agree; ldd should either
+ trace dynamic linker as expected;
or
+ exit with EPERM.

I have an idea how to fix it.
------- Comment #15 From 2002-06-10 13:29:27 -------
Fixed ldd in
glibc-utils-2.2.5-alt6
------- Comment #16 From 2002-06-10 13:29:27 -------
Fixed ldd in
glibc-utils-2.2.5-alt6