file ownership changed to numbers

[Rosli Ahmad]

Hi,
I don't know what has happened but all of our files ownership has been changed to numbers such as 0,1 etc. We did execute 'cleanup' utility to free spaces in /var. What we clean is attached, but I wonder if that has anything to do with the cleanup or removed patches.

Pls. help!!!

thnks.
-rosli-

[Robert-Jan Goossens]

Hi,

Could you run the commands,

# pwck
# grpck

Robert-Jan

[Hoefnix]

Normaly when file ownerships change in numbers that indicates that the owner is not know (delete) from the system.
Then the ownership changes in the id from the deleted account. Creating a new account with this id will result in names for the ownership again.

It is strange that this appeare after a cleanup, becouse that should not have anything to do with this.

Regrads,

Peter

[Michael Tully]

Check the entries in /etc/passwd file. It could be that that uid's 0 and 1 are missing.

[Vijaya Kumar_3]

You may need to any file systems filled up like /var or /

-Vijay

[Rosli Ahmad]

Hi,
I've run the pwck & grpck, both with return code 0. However the /etc/passwd date was modified at 12:37 today. I don't think it has anything to do with cleanup as it was executed later ie. 12:48pm.
I checked the /etc/passwd, all the id's are there, 0 for root, 1 for daemon and so on.
Pls. advise what do I have to do to revert to original setup. Don't tell me I have to chown all the files 1 by 1.

thnks.
-rosli-

[Robert-Jan Goossens]

How about the permissions for /etc/passwd ?

-r--r--r-- 1 root sys 1361 Dec 31 11:11 passwd

Robert-Jan

[Rosli Ahmad]

Hi,
the /etc/passwd ownership as it is follows:
-r--r--r-- 1 0 security 19112 Jan 13 12:37 /etc/passwd

All the files ownership are represented by their userid no. instead of name.

I wonder if it has anything with the PHCO_27780 patch, the one we install for the cleanup utility.

I'm in really in hot soup now.

regards
-rosli-

[Michael Tully]

Please try this before we do anything else:

# chown root:sys /etc/passwd

and let us know the result please

[Rosli Ahmad]

changed the ownership of /etc/passwd as suggested, but the owner still 0 instead of root. what does this mean?

thnx.

[Hoefnix]

I is strange, the chown works but still numbers.
Does the id command gives the correct result as well:
id root

or id 1

[Rosli Ahmad]

Hi guys,
The id returns:

K370:/> id
uid=0() gid=102(mqm) groups=0(root)
K370:/> id root
uid=0() gid=3(sys) groups=0(root),1(other),2(bin),4(adm),5(daemon),6(mail),7(lp),102(mqm)
K370:/>

I'm login as itt902 which has root equivalent access.

thnks.

[Hoefnix]

a different user then root with id 0 is not something you like to have from security perspective. A better way to get root privelidge is using of SUDO.

Are ther many user with id 0? Is it possible to create a passwd file with only root having id 0 and then test if this is your problem?(normally it should not solve it but to be sure)

[David_246]

Hi Rosli,

Two things are possible -->

1) Your /etc/passwd file is corrupted and cannot read the entries in there. As the root account should always be on top, your complete /etc/passwd-file could be corrupted. Normaly pwck checks for any errors and deletes the erroring entries. You can also do a check manualy for having 7 fields in there seperated with colons (:)
root:*:0:3::/root/home:/sbin/sh

2) You have bad permissions on the /etc/passwd or using ACL's or using a security program like CA's eTrust. This just does not let you allow to read the password file.

As a help-tool you might be able to use the following command :

cat /etc/passwd | od -c | more

This prints all characters inclusief the weard ones. Maybe a ^H is added without seeing this character. od-c eliminates this possible problem. Be very carefull in using this and make sure a root login remains !!

Ones logged out you mighthave a big difficulty in getting back in as root. Also make sure you have a backup-file of the /etc/passwd and maybe also a /etc/shadow.

Best Regards David

[Rosli Ahmad]

Thank you all, we believe it's one of our propagation agents is the culprit. We have stop the agent and the file ownership is back to normal. It's writing to /var but started behaving weirdly when /var is full. That's our findings as at this moment. We'll try to start the MQ propogation again and see what'll happen next.

thnks.

rgds
-rosli-

[Michael Tully]

Rosli,

This may sound dumb, but I have seen before where an alias was created that ran 'ls -n' which will show the files as uid/gid instead of the owner an not running what you would assume 'ls -l'

Just an afterthought ...

[Bill Hassell]

And just to set your mind at ease, the nmae of a user (rather than the user ID) is purely cosmetic! ALL files and directories are stored with numbers for group and user. The ll command 'helps' us poor humans to better relate to ownerships by reading the passwd and group files to 'decode' numbers into names. The system doesn't care about the names which is why it still runs OK. The fact that the id command shows names seems to indicate that the passwd and group files are OK. It is always useful to run the type command (actually an alias for which -v) and see where your ll command is located:

type ll

Don't bother with which and whereis as they do not consult with the shell about what to do when you type ll. You may find that it is no longer /usr/bin/ll

And as you've found out, /var is crucial to proper system operation. SO many programs and daemons depend on /var so you must have a lot of space as well as daily purging of temporary files and trimming logfiles as needed. Think gigabytes for /var...