.profile .login .cshrc files permissions

[Basel Naamna]

Hi All!
I see that .profile, .login and .cshrc files are read only for owner while in linux'es the owner can read/write


in HPUX:
-r--r--r-- *** .profile

in linux:
-rw-r--r-- *** .login

Why in HPUX these files are create with read-only permission for the owner?
Thank you

[Peter Godron]

Hi,
please address your point feedback in your profile (0 for 27 answers !)

The permissions of the files are down to when root created the account and/or any permission changes thereafter. I suspect the umask for root is set to 333. See "man umask" for further details.

Please also read:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33 on how to reward any useful answers given to your questions.

So far you have not awarded any points !

[Steven E. Protter]

Shalom,

The resaon for the permissions are because the systems administrator wants to control the user profiles.

This is a choice made, normally for security reasons. There are valid reasons to deny users the ability to change their profiles, including maintaining a standard, uniform environment.

SEP

[Matti_Kurkela]

When a new user is created, the default .profile, .login and .cshrc (and possibly other files) are copied from the template directory.
This template directory is /etc/skel.

When SAM or the "useradd" command copies the files, their ownership is automatically transferred to the new user. However, the permission bits won't change.

It seems that by default most new HP-UXes have -r--r--r-- (chmod 444) permissions for those default files in /etc/skel. There can be many reasons for this, but security is *not* one of them.

Most likely it's intended as a sort of "entrance exam": if the user intends to change .profile, he/she must at least be able to use chmod (or an equivalent GUI tool). If the user can do that, he/she probably can be trusted to understand what he/she is doing.

(Once upon a time, some developers had root password to a development server. After a while, they complained that "root login does not work". I investigated, and saw that someone had added the command "bash" at the end of root's .profile, as they knew that changing root's shell was a bad thing.
Unfortunately, there was no .bash_profile for root, so when someone logged in using the root account, /sbin/sh executed .profile, started bash, which again executed .profile, which caused another bash process to be started...
Fortunately, the developers were familiar with the principle of "infinite loop", so corrective education was easy 8-)