perms on xxgdb and loading SO's in xxgdb

perms on xxgdb and loading SO's in xxgdb

Post by Bill Fr » Wed, 26 Aug 1998 04:00:00



I installed RH 5.1 (kernel 2.0.34) about two months ago.
I have a few questions about some odd things:

1) Before I could use xxgdb, I had to set UID on the file.
   It is owned by root, and, even though it's perms were 555,
   it refused to run.  Why did I have to change the perms?
   Did I do wrong, or did someone somewhere just overlook something?

2) I have several 'generic' SO's that I've developed myself.  I have
   them in my only 'lib' directory (based within my home dir) and I
   have altered by LD_LIBRARY_PATH to include my lib dir.  All is
   well and fine when I run an application that uses my SO's.  But
   when I'm debugging an application that uses one of my SO's, the
   [xx]gdb complains that it cannot find the SO.  Therefore, it
   refuses to run/debug the application.  The exect error I get is
   as follows:

/usr/home/bill/develop/proj/wtf/util/pl/plMON/plMON: error in loading
shared libraries
libwtfobj.so.1: cannot open shared object file: No such file or
directory

   My 'plMON' application relies on the following SO's:

     libwtfobj.so.1 => /usr/home/bill/lib/libwtfobj.so.1 (0x40000000)
     libwtftool.so.1 => /usr/home/bill/lib/libwtftool.so.1 (0x40035000)
     libwtftxts.so.1 => /usr/home/bill/lib/libwtftxts.so.1 (0x40044000)
     libpthread.so.0 => /lib/libpthread.so.0 (0x4004b000)
     libstdc++.so.2.8 => /usr/lib/libstdc++.so.2.8 (0x4005a000)
     libm.so.6 => /lib/libm.so.6 (0x4009f000)
     libc.so.6 => /lib/libc.so.6 (0x400b8000)
     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

   Mind you, the application runs perfectly fine; all the versioning
info
   and whatnot associated with the SO's is correct.
   Am I just missing some command line switch or some var/attrib I can
set
   within my [xx]gdb session to help it locate my SO's?

Thanks!

 
 
 

perms on xxgdb and loading SO's in xxgdb

Post by Rudolf Leitg » Wed, 26 Aug 1998 04:00:00




Quote:> 1) Before I could use xxgdb, I had to set UID on the file.
>    It is owned by root, and, even though it's perms were 555,
>    it refused to run.  Why did I have to change the perms?
>    Did I do wrong, or did someone somewhere just overlook something?

This sounds very odd. What exactly did xxgdb say before you set it SUID ?
Did it complain about missing libraries, ...? If it did, try to run

        strace -o results xxgdb

and look in results for system calls that fail (files it doesn't find, ...)
That should give you a hint why xxgdb is unhappy.

Quote:> 2) I have several 'generic' SO's that I've developed myself.  I have
>    them in my only 'lib' directory (based within my home dir) and I
>    have altered by LD_LIBRARY_PATH to include my lib dir.  All is
>    well and fine when I run an application that uses my SO's.  But
>    when I'm debugging an application that uses one of my SO's, the
>    [xx]gdb complains that it cannot find the SO.  Therefore, it
>    refuses to run/debug the application.  

This is a result from the original problem: Since xxgdb is SUID, it and
any of its children (the process you want to debug would be one of them)
will ignore LD_LIBRARY_PATH. This is a necessary security feature, since
otherwise you could provide your own modified version of the C library (or
any other library), serve it to an SUID program and become superuser.

So I would recommend: Find out why xxgdb needs to run SUID (it shouldn't
have to!). Once you resolve that, you should be alright.

Rudi

--

         | | | | |
       \   _____   /      
          /     \                      B O R N
      -- | o   o |  --                   T O
      -- |       |  --                S L E E P
      -- | \___/ |  --                   I N
          \_____/                   T H E   S U N
        /          \    
         | | | | |

 
 
 

1. perms on xxgdb and loading SO's in xxgdb

I installed RH 5.1 (kernel 2.0.34) about two months ago.
I have a few questions about some odd things:

1) Before I could use xxgdb, I had to set UID on the file.
   It is owned by root, and, even though it's perms were 555,
   it refused to run.  Why did I have to change the perms?
   Did I do wrong, or did someone somewhere just overlook something?

2) I have several 'generic' SO's that I've developed myself.  I have
   them in my only 'lib' directory (based within my home dir) and I
   have altered by LD_LIBRARY_PATH to include my lib dir.  All is
   well and fine when I run an application that uses my SO's.  But
   when I'm debugging an application that uses one of my SO's, the
   [xx]gdb complains that it cannot find the SO.  Therefore, it
   refuses to run/debug the application.  The exect error I get is
   as follows:

/usr/home/bill/develop/proj/wtf/util/pl/plMON/plMON: error in loading
shared libraries
libwtfobj.so.1: cannot open shared object file: No such file or
directory

   My 'plMON' application relies on the following SO's:

     libwtfobj.so.1 => /usr/home/bill/lib/libwtfobj.so.1 (0x40000000)
     libwtftool.so.1 => /usr/home/bill/lib/libwtftool.so.1 (0x40035000)
     libwtftxts.so.1 => /usr/home/bill/lib/libwtftxts.so.1 (0x40044000)
     libpthread.so.0 => /lib/libpthread.so.0 (0x4004b000)
     libstdc++.so.2.8 => /usr/lib/libstdc++.so.2.8 (0x4005a000)
     libm.so.6 => /lib/libm.so.6 (0x4009f000)
     libc.so.6 => /lib/libc.so.6 (0x400b8000)
     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

   Mind you, the application runs perfectly fine; all the versioning
info
   and whatnot associated with the SO's is correct.
   Am I just missing some command line switch or some var/attrib I can
set
   within my [xx]gdb session to help it locate my SO's?

Thanks!

2. switch OS without rebooting?

3. xxgdb: WWhhaatt''ss uupp !!

4. HOWTO compile PGP & ELF

5. xxgdb on linux won't link?

6. Solaris OS disk from a Sparc5 to a Sparc20

7. HELP: can't compile xxgdb

8. Proftp on intel Solaris9

9. xxgdb isn't working under XFree 3.1

10. xxgdb doesn't show which line of code it is on

11. Xxgdb won't compile under XF 3.1.2 ... grrrrrr ....

12. How to use xxgdb -- I've got a problem

13. xxgdb won't build under RedHat 5.1