setuid scripts and dynamically loaded libraries 
Author Message
 setuid scripts and dynamically loaded libraries

I ran into an interesting problem recently that I thought I should
share, so others won't be quite as stumped as I was.

I'm running perl on SunOS and had compiled and installed the Sybase
modules for some of our developers.

One person was using a setuid wrapper script to execute a perl script
that uses Sybase::DBlib and was getting a failure from ld.so that
said:

        ld.so: libsybdb.so.10: not found

Yet when the perl script is run by itself (by the user to whom the
wrapper is setuid) the script runs fine.

Digging through the ld man page I found this:

                           NOTE:  when  running  a  set-user-  or
          set-group-ID   program,  ld.so  will  only  search  for
          libraries  in  directories  it  "trusts",   which   are
          /usr/lib,  /usr/5lib,  /usr/local/lib,  and  any direc-
          tories specified within the executable as a  result  of
          -L options given when the executable was constructed.

Which says that it would trust -L options on perl.  But perl the
executable knows nothing about Sybase or the libraries in it, so when
DBlib.so gets loaded, it refers to libsybdb.so.10, but because the -L
options were applied to DBlib.so, they get ignored (or so it seems).

The solution I came up with was to go back and make the DBlib.so and
CTlib.so shared object libraries use the full pathnames to the Sybase
libraries, therefore bypassing the library searching that ld.so does.
This solution seems to work just fine.

Now for some questions:

- Is there a better way to solve this problem that the one I outlined
  above?

- When implementing my solution, I could find no easy way to get
  MakeMaker to allow me to put the full paths to all the libraries in
  the LIBS parameter to WriteMakefile.  Is there a way to allow this.

--
-- Mark Osbourne



Tue, 01 Dec 1998 03:00:00 GMT  
 setuid scripts and dynamically loaded libraries



Quote:
> I ran into an interesting problem recently that I thought I should
> share, so others won't be quite as stumped as I was.

> I'm running perl on SunOS and had compiled and installed the Sybase
> modules for some of our developers.

> One person was using a setuid wrapper script to execute a perl script
> that uses Sybase::DBlib and was getting a failure from ld.so that
> said:

>    ld.so: libsybdb.so.10: not found

> Yet when the perl script is run by itself (by the user to whom the
> wrapper is setuid) the script runs fine.

> Digging through the ld man page I found this:

>                            NOTE:  when  running  a  set-user-  or
>           set-group-ID   program,  ld.so  will  only  search  for
>           libraries  in  directories  it  "trusts",   which   are
>           /usr/lib,  /usr/5lib,  /usr/local/lib,  and  any direc-
>           tories specified within the executable as a  result  of
>           -L options given when the executable was constructed.

> Which says that it would trust -L options on perl.  But perl the
> executable knows nothing about Sybase or the libraries in it, so when
> DBlib.so gets loaded, it refers to libsybdb.so.10, but because the -L
> options were applied to DBlib.so, they get ignored (or so it seems).

> The solution I came up with was to go back and make the DBlib.so and
> CTlib.so shared object libraries use the full pathnames to the Sybase
> libraries, therefore bypassing the library searching that ld.so does.
> This solution seems to work just fine.

> Now for some questions:

> - Is there a better way to solve this problem that the one I outlined
>   above?

Use the LD_RUN_PATH env var or the -R flag to ld (see the ld manual).

Quote:
> - When implementing my solution, I could find no easy way to get
>   MakeMaker to allow me to put the full paths to all the libraries in
>   the LIBS parameter to WriteMakefile.  Is there a way to allow this.

MakeMaker offers some automated support for LD_RUN_PATH but I
forget how it works. Read the MakeMaker manual and the comments
in the generated Makefile which relate to LD_RUN_PATH.

Tim.



Sat, 05 Dec 1998 03:00:00 GMT  
 setuid scripts and dynamically loaded libraries

[...]

Quote:
> > I'm running perl on SunOS and had compiled and installed the Sybase
> > modules for some of our developers.

> > One person was using a setuid wrapper script to execute a perl script
> > that uses Sybase::DBlib and was getting a failure from ld.so that
> > said:

> >       ld.so: libsybdb.so.10: not found

[...]

Quote:
> > The solution I came up with was to go back and make the DBlib.so and
> > CTlib.so shared object libraries use the full pathnames to the Sybase
> > libraries, therefore bypassing the library searching that ld.so does.
> > This solution seems to work just fine.

> > Now for some questions:

> > - Is there a better way to solve this problem that the one I outlined
> >   above?

> Use the LD_RUN_PATH env var or the -R flag to ld (see the ld manual).

Unfortunately, on SunOS 4.1.[123] (which I should have mentioned
specifically when I was describing the problem) ld knows nothing about
LD_RUN_PATH or the -R option.  

Quote:
> > - When implementing my solution, I could find no easy way to get
> >   MakeMaker to allow me to put the full paths to all the libraries in
> >   the LIBS parameter to WriteMakefile.  Is there a way to allow this.

> MakeMaker offers some automated support for LD_RUN_PATH but I
> forget how it works. Read the MakeMaker manual and the comments
> in the generated Makefile which relate to LD_RUN_PATH.

The MakeMaker stuff for LD_RUN_PATH is working just fine because the
final link is always preceeded by LD_RUN_PATH="/path/to/sybase:/lib"
on both my SunOS 4.1.x box and my Solaris 2.[345] boxes.


Mon, 07 Dec 1998 03:00:00 GMT  
 setuid scripts and dynamically loaded libraries



Quote:


> [...]
> > > One person was using a setuid wrapper script to execute a perl script
> > > that uses Sybase::DBlib and was getting a failure from ld.so that
> > > said:
> > >  ld.so: libsybdb.so.10: not found
> > Use the LD_RUN_PATH env var or the -R flag to ld (see the ld manual).

> Unfortunately, on SunOS 4.1.[123] (which I should have mentioned
> specifically when I was describing the problem) ld knows nothing about
> LD_RUN_PATH or the -R option.  

Ah, SunOS 4.1. Try

        cd /usr/lib
        ln -s /path/to/your/libsybdb.so.10

Tim.



Tue, 08 Dec 1998 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. extension/dynamically loaded library

2. Help: can't load library error when trying to execute cgi(perl)script

3. dynamically change setuid

4. Dynamically loaded modules initialisation?

5. problem of loading module dynamically

6. Dynamically loading a c object

7. loading perl code dynamically

8. Dynamically loading C++ objects?

9. Can I dynamically load g++ code?

10. Unresolved symbol dynamically loading an xsub

11. dynamically loading perl variables

12. Dynamically loading perl modules

 

 
Powered by phpBB® Forum Software