Permissions for /home/<user> .profile and .login

[Glenn Mitchell_2]

Some of our Manufacturing DB functions locked up after I changed the /home user's .profile and .login from rw-r--r--to r--r--r-- (trying to tighten down security settings to comply with Sarbanes-Oxley). I changed the permissions back to rw-r--r-- after we noticed the problems but it seems the damage is not so easily corrected. I noted that all of the files in the affected /home directories had their user name changed to the user's UID number. Am I going to have to go to each directory and manually change (chmod) each UID back to the name to correct this mistake - or is there an easier way to approach this problem? OR... Am I even seeing the correct problem? Please advise. We have the db back up but we did this by executing it under root login.

[David Child_1]

Glenn,

It sounds like something else may have changed. Changing the permissions to 444 on the files you listed should not cause these kinds of problems. More telling is you mention the files all got changed to the UID.

File ownership is always in reality just the UID. /etc/passwd file is referenced for that UID and the name is pulled from there. It sounds like the UID/owner was changed on these files. If you were to grep for the user you are refering in /etc/passwd I believe you will notice that the UID is not the same as the UID that owns the files.

A quick way to fix (especially if this was a global change) would be:

find / -user bad_user_id -print | xargs chown correct_user_id

where bad_user_id is the UID that now owns the files and correct_user_id is either the login name (e.g. oracle) or it's UID.

David

[Mel Burslan]

As David said, the change in the .login or .profile permissions do not cause the effect of changing username to UID in the file ownership fields. It sound like you have restricted the file permission a little too hastily and you can not reference the /etc/passwd file with the current permissions. If you are running a trusted system, make sure the file permissions in the /tcb/files structure is still good as well.

[Glenn Mitchell_2]

I've checked the /etc/passwd and can not find any problem (yet). The server is a Trusted System. I checked the /tcb/files/auth and noted that each user had root as the owner. Is this correct - or do I go through and change the owner for each?

[Geoff Wild]

Question I have is - why are you changing the permissions of .profile/.login? they should be owned by the user anyways - and even if they are 444 - they can still over write them....not having the users access their own files isn't really part of SOX....

Rgds...Geoff

[Glenn Mitchell_2]

I just reviewed the SOX instructinons and it looks like I didn't interpret them correctly... It state that the following files require action:

/etc/profile - all users read access only

/etc/login - should not exist on the system

.profile (for each home directory) - only user and root to have write access

.login (for each home directory) - does not exist on the system

cshrc (for each home directory) - file(s) do not exist on the system

All this to prevent access of hackers and prevent malicious-type commands.

So... I should not have changed the permissions of .profile and should have removed the .login files

[Patrick Wallek]

The permissions on the files under /tcb are OK. They are supposed to be owned by root.

Removing write permission from .profile and .login should not have cuased any problems.

The ownership of the files being a UID number indicates that the user that used to own the files no longer exists in /etc/passwd, OR, the users don't have read access to /etc/passwd so that they can resolve UIDs to user names.

The /etc/passwd file should be readable by everyone (444 permissions).

Is the same UID the owner of ALL files? Or is it different for the files in each home directory?

[Mel Burslan]

You should not remove the .login and .cshrc file blindly as they can be used by the users whose default shells are csh (most common example is SAP's adm accounts. For some reason beyond my understanding, SAP AG GmbH developers are in love with csh), for which the removal of these files may break their operation. Again, as you have figured, leaving the access open for the file owner is not a threat and not a pitfall for SOX.

My tcb file ownership/permission settings are like this

-rw-rw-r-- 1 root root 157 Nov 18 2003 mysql

just as a reference for you to compare and we do not have any problems like you described.

As Patrick said in the previous post, UID instead of username may indicate that the user which owned those files may no longer exist. Make sure the UID and the usernames are still in sync in the passwd file. Sometimes, I have seen, converting to a trusted base or someone trying to tidy up the /etc/passwd file can cause this kind of grief by simply fatfingering something in an otherwise very simple script.

[Glenn Mitchell_2]

I found my /etc/passwd file had r--r----- permissions and have changed this to r--r--r--. I comopared SAM Users with /etc/passwd and see no differences.

[Mel Burslan]

for the hypotetical file below

-rw-r--4-- 1 21347 users 439 Apr 21 2004 /home/user1/textfile

what you need to compare is if user1's UID in /etc/passwd is actually 21347 or something else. If it is something else, this will explain the replacement of UIDs with usernames, otherwise there must be another reason.

[Glenn Mitchell_2]

Strange... After making my /etc/passwd permissions r--r--r-- I went into each /home/userx directory and found all the files back to the correct user named ownership instead of UID number(????). This is good - but unexplainable by me. I drilled down a few directories checking the UIDs (now user name) against the /etc/passwd file and found no differences.

I guess I need to wait and see what the user reaction is to address this further. Do you have any advice on what I should do now otherwise?

[Senthil Kumar .A_1]

Hi Glenn..

This explains it all...

$ ll /etc/passwd
-rw-r--r-- 1 root root 116396 May 31 13:57 /etc/passwd

example..in my system..

if my user id was senthil..

and the passwd perm would be : -r--r-----

then when i login as senthil.. i will not have permissions to read passwd file..to make a co-relation with the UID and username..this explains why as your login you read only UID instead of username.

Since you corrected the issue,.. now it displays fine.

So you did solve the problem by fixing the permissions on /etc/passwd.

Regards.

[Mel Burslan]

Well, there not much more to explain after this moment. The /etc/passwd files should be open to read by everyone, i.e., minimal permission of 444. It is owned by root:sys but every user need to be able to read it, so the "others" permission needs to be set to true. When a file long listing (ll) is provided, file ownerships are provided by the filsystem structure as UID:GID pairs. It is the ls executable's job to lookup this data and convert it to a username:groupname pair, and the files it uses to look them up are /etc/passwd and /etc/group. If one of them does not have permission to be read by "others" you will experience the same thing for the user and/or group field.

There should not be any further complaints from your users

[Senthil Kumar .A_1]

Hi Glen,

I even tested my response..Please check below..

After modifying the permission on /etc/passwd

$ ll -d senthil
drwxr-xr-x 2 senthil users 96 May 31 11:29 senthil
$ ll
total 0
drwxr-xr-x 2 0 root 96 Dec 18 2003 lost+found
drwxr-xr-x 2 104 users 96 May 31 11:29 senthil
$ ll -d /etc/passwd
-r--r----- 1 0 root 504 May 31 11:28 /etc/passwd



After restoring back the permission on /etc/passwd.

$ ll
total 0
drwxr-xr-x 2 root root 96 Dec 18 2003 lost+found
drwxr-xr-x 2 senthil users 96 May 31 11:29 senthil
$ ll -d /etc/passwd
-r--r--r-- 1 root root 504 May 31 11:28 /etc/passwd

[Glenn Mitchell_2]

Thank you all for you assistance in solving my problem. I will go through each /home/user directory and make sure the .profile file has rw-r--r-- permissions set - and not mess with them anymore. I will also investigate what the SAP users in my company have as SOX restrictions for .login and cshrc files and relay your comments regarding their need for correct operation of the db.
Thank you again.