Avoid users to remove the .profile

[Clemens van Everdingen]

How can I avoid that a user is deleting his own .profile form his home dir ?

Sticky bit is not the solution. I tested this.

[Massimo Bianchi]

Hi,
assigning the root:bin ownership, and permission rrr ?

Massimo

[Stefan Farrelly]

I believe the only way to do this is make the permissions on the users home dir 570 - ie. they do not own their own directory, or else they can remove .profile - even if it is owned by root and not writeable by anyone or a link. Any user who owns their own dir can always delete anything in it.

The user will be able to create files in their home dir by using the group write permission, but will allow others in the same group to enter their directory and do likewise. Perhaps the user who you want to stop removing their .profile should have a group all of thier own.

[Clemens van Everdingen]

Stefan,

I already found this solution. I hoped someone has found another way around :)

Too bad..... this is a nice feature of HP-UX.

Thanks,
Clemens

[Zeev Schultz]

Stefan is correct,only by changing the $homedir
to read-only.Otherwise user can do whatever he likes.Another options are : using aliases,changing rm binary to point to some another script with conditions checks or (thats a wild one :)) mount read-only .profile
from some place.

[Tim D Fulford]

Surely setting the home dir to 570 is not "practical"
1 - the user will not be able to write to their home dir
2 - if the user is in the "group" then they can/will do chmod on their home dir.

I think the only way is to set the permissions of the .profile to 444 (read,read, read) & the ownership root:sys.

To me this is an upside down question, usually security people will be saying "How do we stop people creating .profiles, as it is a security risk"!

Just my 0.02???

Regards

Tim

[RAC_1]

Time solution seems right to me. Giving 570 to hiome dir will not serve purpose if user is in group.

[Jdamian]

Massimo and Tim:

Removing write permission to a file doesn't prevent removing from directory.

[Stefan Farrelly]

Tim,

1. If the permission are 570 on the users home dir and he belongs to the group that has rwx then he CAN write to his home dir. This is what I said in my earlier reply.

2. If the user does NOT own his home dir then he CANNOT change its ownership, so .profile will remain safe and undeleteable (if owned by root:sys and permissions 444).

It is a good solution, and works. Try it yourself.

[Jdamian]

ACL should be useful in this situation.

[hein coulier]

stefan,

try this :

mv .profile /tmp/.profile
cp /tmp.profile .profile
vi .profile
chmod 444 .profile
chown root:sys .profile

and noone will ever notice the changes you made ;-)

[Tim D Fulford]

Stefan

Hi... I did not appriciate the subtlties of your reply!!!

Anyway, I also remember a question on HP certification which said words akin "to which one of these permissions is unsuitable"
a r--r--r--
b rw-rw-r--
c r--rw-rw-

The answer is c because the group & world perms are greater than the owner perms. Hence my heckles were raised as perms of 570.

Regards

Tim

[Stefan Farrelly]

Hein,

how can you mv .profile to /tmp if you dont own the directory you are in ? you get an error; mv: .profile: cannot unlink, Not owner

I have spotted a problem, of course the homedir permissions must be 1570, not 570, in addition to owned by root. The sticky bit needs to be set to ensure only the owner can rm/mv files in it.

[hein coulier]

Stefan, you're right that you can't mv if you set the sticky bit, but you can with the 570 permissions.

To me, the solution with the sticky bit is bulletproof. I could be wrong, but is it possible in some linux'es they create a 'presonal secondary group' per user in order to provide the functionalities we're dicussing here ?

[RolandH]

Hi Clemens,

of course you can prevent that a user deletes its own .profile but you can not prevent that he/she always use its own one. ie .profile must be readable for the user.

-r--r--r-- 1 root sys 1158 Mar 17 16:35 .profile

Ok I can't change it if .profile has this permissions. But I can do this
cat .profile > .my_profile

No I have a .my_profile with my user permisssions and I can do changes in there.

and I can always do this
$ . ./.my_profile

The only thing that I need for that a directory where I'm allowed to write.
So, if ask your question because some users should not change there environment then you should ask:

CAN I MADE ENVIRONMENT VARIABLES READ ONLY??

I have no idea!!

Roland

[Kent Ostby]

There is always the workaround of having a cron job that checks all the users to see if they have a .profile and if they dont, copy in a default one.

I had to do a similar thing on my system when I couldnt change the user behavior :-)

[Clemens van Everdingen]

@,

Thanks all for the replies !
Everybody is suggesting more or less a similar workaround, since there is no default solution.

I think I use the workaround from which Kent also suggested.

Thanks ALL,
Clemens

[Volker Borowski]

Clemens,

include a check if the user did change his login shell as well.
You might have a correct .profile all in place, but if the user had been able to "chsh /usr/bin/csh" he would be bound to .login and .cshrc instead of .profile

From "man chsh" http://reinolinux.fe.up.pt/cgi-bin/man2html?chsh+1

"... A normal user may only change the login shell for their own account, ...."

Which might certainly not what you want him to do ?

Several doors to close I guess.

Volker

[Robert Salter · Accepted solution]

Clemens,

This may be a little late, but in the same vein as Kent's reply. Why not put the .profile check in /etc/profile, that way when a user logs in and they're profile is missing a default .profile is copied over. See attached.

I also added some logging so you can see who keeps getting their .profile deleted.

With further tweaking you could do a lookup of the user and copy any custom profile depending on that user's environment needs. I.E. /etc/uskel vs /etc/skel as I used in the example.

later,

bob

[Fred Martin_1]

When I was an SA on a Sun server, we had a single standard .profile that we wanted everyone to use. We created a link from all home directories to the one master .profile.

Then, once a day, a scheduled job went to each home directory and if the link was missing, it was re-created. If the user put his own .profile in there, it was removed first.

[W.C. Epperson]

I had such a problem once upon a time, with someone I couldn't get fired for breaking policy.

Solution was at the bottom of /etc/profile:

if [ -f /etc/userprofiles/$LOGNAME ] ;then
. /etc/userprofiles/$LOGNAME
fi

Appropriate permissions made this functional equivalent of $HOME/.profile, but non-tamperable.