Hi,
    I have an executable oracon (to connect to Oracle database) on
Solaris 8 using oracle shared object: libclntsh.so.9.0.

In runtime there is another process called "dbserv" that forks and
exec's the "oracon", which has following permission:

-rwxr-xr-x   1 port     staff     315508 Jan  9 16:24 dbserv

When the "dbserv" is run as "root" : It works fine exec'ing "oracon"
with dynamically loading libclntsh.so.9.0

But, if it is run as logged in user (other than root), I get following
error:

--------------------------
ld.so.1: oracon : fatal: libclntsh.so.9.0: open failed: No such file
or directory
-------------------------
NOTE : "dbserv" reads the correct LD_LIBRARY_PATH from a config file.

I have found that when "dbserv" has different Real User Id and
Effective User Id (say, USER ID = 1015 EFF Id = 0), I get the problem.
But if they are same, it works fine.

Can anyone help me find the reason behind this occurence.

Appreciate your co-operation.
Dibyendu

dibyendu.roy@nyc.com (Dibyendu Roy) writes:
>     I have an executable [...] using oracle shared object: libclntsh.so.9.0.
> 
> When the "dbserv" is run as "root" : It works fine exec'ing "oracon"
> with dynamically loading libclntsh.so.9.0
> 
> But, if it is run as logged in user (other than root), I get following
> error:
> 
> --------------------------
> ld.so.1: oracon : fatal: libclntsh.so.9.0: open failed: No such file
> or directory
> -------------------------
> NOTE : "dbserv" reads the correct LD_LIBRARY_PATH from a config file.
> 
> I have found that when "dbserv" has different Real User Id and
> Effective User Id (say, USER ID = 1015 EFF Id = 0), I get the problem.
> But if they are same, it works fine.

Read the SECURITY section of the ld.so.1 manpage.  If the real & effective
uid differ, LD_LIBRARY_PATH is subject to special restrictions.  You need
to place your shared library into a "secure" directory for this to work.

-- Anton

Hi Anton,
        Thanks you so much. 
But do you have any idea why this worked on Solaris 2.6 box. I
followed the same thing there, it worked fine. And in case of Solaris
8, it is not.
Is it something security constraint is imposed after Solaris 2.6.

--Dibyendu

Anton Rang <rang@visi.com> wrote in message news:<ybt8yl427p5.fsf@isis.visi.com>...
> dibyendu.roy@nyc.com (Dibyendu Roy) writes:
> >     I have an executable [...] using oracle shared object: libclntsh.so.9.0.
> > 
> > When the "dbserv" is run as "root" : It works fine exec'ing "oracon"
> > with dynamically loading libclntsh.so.9.0
> > 
> > But, if it is run as logged in user (other than root), I get following
> > error:
> > 
> > --------------------------
> > ld.so.1: oracon : fatal: libclntsh.so.9.0: open failed: No such file
> > or directory
> > -------------------------
> > NOTE : "dbserv" reads the correct LD_LIBRARY_PATH from a config file.
> > 
> > I have found that when "dbserv" has different Real User Id and
> > Effective User Id (say, USER ID = 1015 EFF Id = 0), I get the problem.
> > But if they are same, it works fine.
> 
> Read the SECURITY section of the ld.so.1 manpage.  If the real & effective
> uid differ, LD_LIBRARY_PATH is subject to special restrictions.  You need
> to place your shared library into a "secure" directory for this to work.
> 
> -- Anton

dibyendu.roy@nyc.com (Dibyendu Roy) writes:
> Hi Anton,
>         Thanks you so much. 
> But do you have any idea why this worked on Solaris 2.6 box. I
> followed the same thing there, it worked fine. And in case of Solaris
> 8, it is not.
> Is it something security constraint is imposed after Solaris 2.6.

Most likely libclntsh.so is (or was, on the Solaris 2.6 box) in /usr/lib.

In Solaris 2.6, /usr/lib was considered the "trusted" directory.  In
Solaris 8, /usr/lib/secure became the "trusted" directory instead.

I think this is to improve security -- if an administrator has a
library which may not be safe to use as root, it can be placed into
/usr/lib, and setuid programs won't use it.  A library which is known
to be safe can be placed into /usr/lib/secure instead.

It's also worth noting that if the application is linked to use a full
path (e.g. /usr/lib/libclntsh.so.9.0) it should run fine -- the secure
directory is only needed if the library is linked by name, but not
full path.

-- Anton

Anton Rang <rang@visi.com> writes:

>In Solaris 2.6, /usr/lib was considered the "trusted" directory.  In
>Solaris 8, /usr/lib/secure became the "trusted" directory instead.

"Trusted" in this sense means "can be loaded with LD_PRELOAD into set-uid
executables".

With so much stuff piled into /usr/lib, we felt that the risk of being
able to preload any odd library into a set-uid executable was just too great.

>I think this is to improve security -- if an administrator has a
>library which may not be safe to use as root, it can be placed into
>/usr/lib, and setuid programs won't use it.  A library which is known
>to be safe can be placed into /usr/lib/secure instead.

Set-uid apps linked against libraries in /usr/lib will still load them.

>It's also worth noting that if the application is linked to use a full
>path (e.g. /usr/lib/libclntsh.so.9.0) it should run fine -- the secure
>directory is only needed if the library is linked by name, but not
>full path.

If it's in /usr/lib, ld.so.1 will load it.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.