Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
General
cancel
Showing results for 
Search instead for 
Did you mean: 

can we remove following HP-UX files

SOLVED
Go to solution
Khairul_1
Frequent Advisor

can we remove following HP-UX files

Hi We have found many files in /usr/lib. Some user oracle but id 191. Can we remove this files? I am attaching the orphaned file. Please help me.
==============

# find / \( -nouser -o -nogroup \) -print
/usr/lib/nls/msg/C/ldd.cat lrwxr-xr-x 1 oracle 191 14 Jan8 2004 ldd.cat -> ./fastbind.cat
/usr/lib/hpux32/libCsup.so
/usr/lib/hpux32/libl.so lrwxr-xr-x 1 oracle 191 11 Jan8 2004 liby.so -> ./liby.so.1
/usr/lib/hpux32/libl_thread.so lrwxr-xr-x 1 oracle 191 18 Jan8 2004 libl_thread.so -> ./libl_thread.so.1
=============
14 REPLIES
Yogeeraj_1
Honored Contributor

Re: can we remove following HP-UX files

hi,

Some of these files might have been created or linked during the installation of your Oracle software.

Why do you want to remove these files?

kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Matti_Kurkela
Honored Contributor
Solution

Re: can we remove following HP-UX files

NO. Do not remove those files.

If you remove all the files listed in your attachment, at least these things will happen:

- you won't be able to run any PA-RISC binaries (using the Aries emulator), because the PA-RISC versions of some critical libraries will be gone (in /usr/lib/hpux32 and /usr/lib/hpux64).

- as /usr/ccs/bin/cc is gone, anything that uses the "bundled cc" compiler of HP-UX may be in trouble. This includes configuring your kernel!

- removing the listed files from /usr/include/aCC_std will make it impossible to compile most programs. At least C++ programs are affected; maybe even plain C programs.

- you will lose the commands funzip, unzip, unzipsfx, zipgrep and zipinfo and their man pages

- removing /var/adm/crash/crash.2 is not immediately harmful, but you will lose the "crashinfo" tool and its install documentation. If you have this stored elsewhere or won't need it, this is not a problem. The "crashinfo" tool is not mandatory.

There may be more bad effects.

Those files do not look at all Oracle-related. It might be important to find out why the owner and group of those files have been changed like that. Almost all of those files are "sysadmin territory" and are usually changed only by swinstall.

This looks like someone with root privileges may have made a mistake. If this is so, find out what he/she tried to do and ensure that he/she learns what went wrong and how it should have been done.

If the mistake is not found, beware: in theory, this might also be caused by an intruder that was not completely successful in covering his/her tracks.

---------------

The files in /usr/local/bin and /usr/local/man/man1 seem to be owned by root, and the group ID is 1307. This looks like sloppy packages from the HP-UX Porting and Archive Centre. Some of their swinstall depots don't specify the group of files to be installed, so the group number is inherited from the system that was used in creating the depot. If the newest version of this package in the Porting Archive still has this problem, it might be useful to contact the author of the package and politely request them to fix their package so that it sets the correct group ownership.

Because the group does not have any more permissions than "all others" (i.e. no group write permissions), it should not cause any significant security problems. Of course, it looks ugly and untidy.

---------------
MK
MK
Khairul_1
Frequent Advisor

Re: can we remove following HP-UX files

this file using user id oracle but what is 191 is it group id?

Audit team proposed for remove orphaned file from system.
We are using following command for fined orphaned files from system
# find / \( -nouser -o -nogroup \) -print

Please help us how we solve the issue without remove the files?
Yogeeraj_1
Honored Contributor

Re: can we remove following HP-UX files

hi again,

191 is the group id that no longer exist!

you may wish to check your /etc/group

it can also be that a particular group ID has been changed.

Beware that this does not automatically imply that the file is no longer in use!!

kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Matti_Kurkela
Honored Contributor

Re: can we remove following HP-UX files

Some of the listed files are actually symbolic links. You must use chown/chgrp option "-h" to change the owner/group of a symbolic link.

The ownership of a link is mostly a cosmetic thing: when accessing a file through a symbolic link, the permissions and ownership of the link is _ignored_: only the actual file's permissions and ownership have meaning. So the security effect of a strange group/ownership is minimal, probably no effect at all.

For all the listed files in /usr/lib and /usr/include, the correct group is most likely "bin".

Wait... I just noticed a strange thing.

Just now, I got access to a HP-UX 11.23 (BUNDLE11i is September 2004 version, QPKBASE & QPKAPPS are March 2006). I tried to check what the user & group of those files should be.

I noticed that _all_ those files in /usr/lib and /usr/include you listed are symbolic links, and all have group 191 in my server too!

The owner of the files on my server is "iwww", which is different from your case... but the UID number of "iwww" in my server is 103. I'm guessing that in your server, the user "oracle" has UID 103. Am I correct? (run "id oracle" to check)

This might actually be a bug in HP-UX 11.23 installation system: open a support call to HP to see if this is a known bug.

MK
MK
Dennis Handly
Acclaimed Contributor

Re: can we remove following HP-UX files

Unfortunately these symlinks were created due to a manufacturing problem in the lab. (191 is our lab's GID.)

If you remove those .so files, you will not be able to link any applications to those shlibs.

>Matti: you won't be able to run any PA-RISC binaries (using the Aries emulator), because the PA-RISC versions of some critical libraries will be gone (in /usr/lib/hpux32 and /usr/lib/hpux64).

I'm not sure how that could happen. PA libs aren't in hpux##/.

>This includes configuring your kernel!

The kernel no longer uses cc_bundled.

>- removing the listed files from /usr/include/aCC_std will make it impossible to compile most programs. At least C++ programs are affected; maybe even plain C programs.

C doesn't use these C++ headers. aC++ user the headers in /opt/aCC/include*/.

>It might be important to find out why the owner and group of those files have been changed like that.

I don't know about all of the files you mentioned but any with 191 are due to a manufacturing error and are fixed on 11.31.

>yogeeraj: 191 is the group id that no longer exist!

(It exits on my system. ;-)

>Matti: Some of the listed files are actually symbolic links. ... So the security effect of a strange group/ownership is minimal, probably no effect at all.

Right.

>For all the listed files in /usr/lib and /usr/include, the correct group is most likely "bin".

Yes.

>I noticed that _all_ those files in /usr/lib and /usr/include you listed are symbolic links, and all have group 191 in my server too!

Yes.

>the UID number of "iwww" in my server is 103. I'm guessing that in your server, the user "oracle" has UID 103.

Yes, 103:191 are the IDs we use to manufacture software.

>This might actually be a bug in HP-UX 11.23 installation system: open a support call to HP to see if this is a known bug.

Well, I've heard of the issue several weeks ago. I don't know if the Response Center has heard about it, so go ahead.
Matti_Kurkela
Honored Contributor

Re: can we remove following HP-UX files

My comment about PA-RISC libraries was a brain-fart on my part: when I wrote my first reply, I did not have a ia64 11.23 machine reachable for a quick check of the details.

I was thinking about the need to have both 32- and 64-bit libraries for PA-RISC emulation and yet another set for native programs. Then I obviously got confused :-(

Nice to see that the root cause is confirmed.

I'll examine our 11.23 ia64 servers a bit more, and will try to write a quick fix for this (otherwise, we will also eventually have some confused system auditors to worry about). Probably something like this:

find /usr/lib /usr/include -xdev -type l -user 103 -group 191 -print | xargs

That's assuming those conditions are specific enough to pick exactly the symlinks affected by this particular problem: that could be verified by putting "ll -d" in place of the first: if it seems to get *only* the correct symlinks, just put something like "chown -h bin:bin" to to actually fix it.

MK
MK
Dennis Handly
Acclaimed Contributor

Re: can we remove following HP-UX files

A customer (more important than you guys :-) filed CR JAGag39681 on this issue.
Tor-Arne Nostdal
Trusted Contributor

Re: can we remove following HP-UX files

Hi,
A quick check on our 11.23 ia64 showed exactly the same.

Dennis > Yes, 103:191 are the IDs we use to manufacture software.

Wouldn't it be advisable to either:
- define this UID/GID in /etc/passwd and /etc/group
- change the owner/group during swinstall

Should all files be owned by bin:bin ?

My list of files attached.

/Tor-Arne
I'm trying to become President of the state I'm in...
Tor-Arne Nostdal
Trusted Contributor

Re: can we remove following HP-UX files

Hi OV.
If you find some "strange files" it could be advicable to check out which software installation they came with.

If the files was installed with swinstall, you can use swlist to identify them.

example:
swlist -l file | grep /usr/lib/hpux32/libCsup.so
OS-Core.CORE2-SHLIBS: /usr/lib/hpux32/libCsup.so
OS-Core.CORE2-SHLIBS: /usr/lib/hpux32/libCsup.so.1
PHSS_35055.CORE2-SHLIBS: /usr/lib/hpux32/libCsup.so.1

Checked which packages the files came with...
find /usr/lib /usr/include -xdev -type l -user 103 -group 191 -print |\
while read FNAME;do
swlist -l file | grep $FNAME
done| cut -d: -f1 | sort -u &

OS-Core.CMDS2-AUX
OS-Core.CORE2-64SLIB
OS-Core.CORE2-SHLIBS
OS-Core.LINKER-PAOBJ
PHSS_34853.CORE2-64SLIB
PHSS_34853.CORE2-SHLIBS
PHSS_34859.CORE2-64SLIB
PHSS_34859.CORE2-SHLIBS
PHSS_34860.CORE2-64SLIB
PHSS_34860.CORE2-SHLIBS
PHSS_35055.CORE2-64SLIB
PHSS_35055.CORE2-SHLIBS
ProgSupport.CXX-INC

/Tor-Arne
I'm trying to become President of the state I'm in...
Dennis Handly
Acclaimed Contributor

Re: can we remove following HP-UX files

>Tor-Arne: Wouldn't it be advisable to either: ...
>Should all files be owned by bin:bin?

Yes. The ownership should be set to bin:bin before we package it.

Thanks for the fileset list. Though I doubt they are in any patches. You need to anchor your grep: grep " $FNAME "
(space at beginning, tab at end.)

(Your script to find them is very slow and not using vector methods. You should find all of the files, then when you do swlist, you should grep -f the previous list.)
Tor-Arne Nostdal
Trusted Contributor

Re: can we remove following HP-UX files

I've cretaed a small script which is better/faster and will give a better view.

You're right about the patches.
A file which already exist and have the wrong ownership will normally maintain the ownership when it is overwritten.
As such when a new version of /usr/lib/hpux32/libcl.so is copied into the system, and this file already existed - the ownership is maintained...
When I do the new search - and include the space and tab, the list of packages is thus reduced.

It does not change the ownership, only reports like shown below:

# /tmp/findit.sh

Reporting files with wrong ownership
and which install packages they came with

Packages:

OS-Core.CMDS2-AUX
OS-Core.CORE2-64SLIB
OS-Core.CORE2-SHLIBS
ProgSupport.CXX-INC

Files in /usr/lib /usr/include owned by uid=103, gid=191:

/usr/lib/hpux32/libcl.so
/usr/lib/hpux32/libm.so
....
I'm trying to become President of the state I'm in...
Tor-Arne Nostdal
Trusted Contributor

Re: can we remove following HP-UX files

The attached script was not posted...
I'm trying to become President of the state I'm in...
Dennis Handly
Acclaimed Contributor

Re: can we remove following HP-UX files

PHSS_35983 was just released to fix the ownership issue.