> But you can be saved. For every LD_ environment variable
> there are _32 and _64 variants. See ld.so.1(1). Thus you could use:
>
> % LD_PRELOAD_32=/...../libjsig.so
Except if they are running Solaris 8 which they are. :-)
In their case, the command that is flagged is "ps", not uptime.
So, they must be calling the ps command somewhere in the startup
of their java application, I imagine. If we set the LD_PRELOAD
just before java is called and unset it immediately after, we can
probably get around this.
Thanks - Rich
Rod Evans wrote On 10/04/05 19:38,:
> Read the error message carefully:
>
>
>>% setenv LD_PRELOAD /usr/j2se/jre/lib/sparc/server/libjsig.so
>>% sunphone
>>ld.so.1: uptime: warning: /usr/j2se/jre/lib/sparc/server/libjsig.so: open
>>failed: illegal insecure pathname
>
> ^^^^^^
>
> sunphone, and the various sub-processes is spawns, are having libjsig.so
> preloaded. But, one sub-process, uptime(1), is setuid. It is this
> process that is generating the warning message
>
> But there's more. The 32-bit binary /usr/bin/uptime is actually an
> isaexec(3c) wrapper. At runtime, the 64-bit variant is executed:
>
> oxpoly 1627. truss -texec uptime
> execve("/usr/bin/uptime", 0xFFBFF104, 0xFFBFF10C) argc = 1
> execve("/usr/bin/sparcv9/uptime", 0xFFBFF104, 0xFFBFF10C)
>
> It is this 64-bit binary that is setuid. Because of this:
>
> i. You couldn't preload libjsig.so anyway, as it is the
> wrong class. Plus, (on my machine anyway) I see no
> 64-bit variant of this library.
>
> ii. crle(1), by default, establishes a cache for 32-bit
> objects. Thus the crle command you used is creating
> a secure directory for 32-bit objects only - the
> 64-bit uptime(1) will not read this cache.
>
> iii. You could use crle -64 to create a 64-bit cache, but
> unless there's a 64-bit libjsig.so available this
> wouldn't be much use.
>
> But you can be saved. For every LD_ environment variable
> there are _32 and _64 variants. See ld.so.1(1). Thus you could use:
>
> % LD_PRELOAD_32=/...../libjsig.so
>
> to preload your library for all 32-bit processes, thereby
> avoiding the 64-bit uptime() that is causing the warning.
>
>
--
Rich Barker, SunONE Development Support Group
Sun Microsystems Technical Assistance Center, Burlington, MA. USA
781-442-1341
rich.barker at sun.com
