mmccaws2 <mmccaws@comcast.net> wrote:
> I did this
> chmod -R 644 /opt/perl_32/lib/5.8.8
> to recursively change the permission in the perl libraries.
> then I started to see the message above.
> /usr/lib/hpux32/dld.so: Unable to find library 'libperl.so'

> how do I repair this. here is the ls on libperl.so

> -r-xr-xr-x 1 bin bin 4324272 Sep 13 23:24 /opt/perl_64/
> lib/5.8.8/IA64.ARCHREV_0-thread-multi-LP64/CORE/libperl.so

Well, chmoding something 644 gives it permissions that look like:

$ chmod 644 foo
$ ll foo
-rw-r--r-- 1 raj users 28672 Feb 14 2007 foo

Which means that owner (in this case raj) has read and write
permissions, and that the group (users) has read permissions and that
everyone else has read permissions.

The example you show for the 64-bit library is "555" which gives
everyone read and execute permissions,

$ chmod 555 foo
$ ll foo
-r-xr-xr-x 1 raj users 28672 Feb 14 2007 foo

but does not give anyone write permissions.

The (dynamic) loader is rather particular about only loading things
which execute permissions. So, for all the libraries at least you
will want to set them to some variation on "555" or "+x" as it were.
I'm guessing 555 is the way to go - you don't necessarily want to give
write permissions to anyone lest they do something nefarious with your
libraries.

I'm not sure what the status of Bastille or the other HP-UX based
security tools might be, but after you have finished trying to undo
what you've done you might want to run one or more of them to check
permissions on the files in the system.

Also, another perusal of the chmod manpage might not be a bad idea to
help reinforce what the octal numbers mean wrt permissions.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...