LIBPATH in 5.3L

SBC Global News

unread,

Oct 14, 2005, 5:05:46 PM10/14/05

to

We are currently testing out 5.3L.

I am finding a few differences from 4.3+.

One is LIBPATH is not passed on to the
job when submitting it in the batch queue.

How do I disable this behavior? Or shall
I say how can I pass on to the child process
the LIBPATH variable?

Thanks in advance.

Laurenz Albe

unread,

Oct 17, 2005, 3:20:46 AM10/17/05

to

Sorry to give such a trivial answer, but your description seems to
suggest that you didn't export the environment variable.

Does the problem go away if you type
export LIBPATH
before invoking the batch job?

Yours,
Laurenz Albe

Bernard Dhooghe

unread,

Oct 17, 2005, 7:03:32 AM10/17/05

to

Tested on 5300-01 and 5300-03.

Confirm the described behavior on both versions.

Solution?

Bernard Dhooghe

C C

unread,

Oct 17, 2005, 12:25:30 PM10/17/05

to

Yes.

A script submits a job to a batch queue:
qprt -P$myqueue -C -T "$PROGID" qbatchexec

The script that submits the above job determines the
queue name (in $myqueue variable) that the job will run under, export all
variables
needed by qbatchexec (another script), including LIBPATH.

When qbatchexec is under the control of the batch queue, I echo $LIBPATH
at the beginning of the script. AND LIBPATH is empty!

This is the scenario.

Thanks for any input on this.
"Laurenz Albe" <inv...@spam.to.invalid> wrote in message
news:11295336...@proxy.dienste.wien.at...

Hajo Ehlers

unread,

Oct 17, 2005, 2:43:58 PM10/17/05

to

Bernard Dhooghe wrote:
> Tested on 5300-01 and 5300-03.
>
> Confirm the described behavior on both versions.
>
> Solution?

I do not know if it helps but i have found on aix 5.1 that if i change
from a lower security and a different shell to root i will lose PATH
and LIBPATH environment. PATH is set to absolut minimum plus extensions
in root's profile.
LIBPATH is wiped out.

Example: ( ksh -> bash -> ksh )
login as root (ksh)
$ echo $LIBPATH
/usr/lib

$su - bashuser
$ echo $LIBPATH
/usr/lib

$su - root
$ echo $LIBPATH
[EMPTY]

The same for a ksh-user ( ksh -> ksh -> ksh )

login as root (ksh)
$ echo $LIBPATH
/usr/lib

$su - kskuser
$ echo $LIBPATH
/usr/lib

$su - root
$ echo $LIBPATH
/usr/lib

So you might check ' which process does have which right' for each
process in you command chain.

Technical Reference: Base Operating System and Extensions, Volume 1
exec: execl, execle, execlp, execv, execve, execvp, or exect Subroutine
...
The LIBPATH variable, when set, is used in favor of LD_LIBRARY_PATH;
otherwise, LD_LIBRARY_PATH is used. These library path variables are
ignored when the program that the exec subroutine is run on has more
privilege than the calling program (for example, an suid program).
...

hth
Hajo

C C

unread,

Oct 17, 2005, 3:17:00 PM10/17/05

to

IBM said that for security, the LIBPATH is removed if you su to another
user.

BUT the parent/child/more_child processes are running within my own
environment. LIBPATH is always blank in all child processes. I may
have to re-export LIBPATH in all scripts as a workaround.

"Hajo Ehlers" <ser...@metamodul.com> wrote in message
news:1129574638....@o13g2000cwo.googlegroups.com...

Hajo Ehlers

unread,

Oct 18, 2005, 3:30:04 AM10/18/05

to

C C wrote:
> IBM said that for security, the LIBPATH is removed if you su to another
> user.

Not only su . The most important point is:

.. exec subroutine is run on has >>>more privilege<<< than the calling
program

So from my understanding your qbatchexec will be started in the
follwoing order

script -> qprt -> qbatchexec

Since qprt has the owner bin:bin i would think that is has more
privilege then the script that will exec qprt.

A solution would be to create a perl suid script which will start the
qprt or like you said all final scripts have to reimport the LIBPATH
variable.

hth
Hajo