$HOME directories changing permission

[josel]

Hello y'all!

Out of no where our system started giving users command prompt ($) instead of taking them to their designated user menus.

I found that the /usr/[userid] directory has -rw-rw-rw- permission or 666 instead of 755. As far as I am concerned, there is nothing in our system that would do this. To make matter worst, it does not happen with all users.

Has any body out here experienced something similar?

thank you all in advance!

Regards;

 

[mcpn]

Hi, I've seen this happen when the user delete's his .profile or the permissions on it means his does not read access to it.

 

[JorGeVaL]

Regarding permissions try the commands integrity and fixmog, remember to read the manual pages for those commands.

I hope this can help

 

[josel]

Thank you mcp and champetu for your suggestions.

I checked for permissions on .profile files and they were all 0600 which I guess is OK. As far as I recall, I never noticed the .profile file missing at all.

I read up on integrity and fixmog and went for it! Following is what I ended up getting:

Change mode of /usr from 0755 to 0775 (y/n)? y
Change owner of /etc/auth/subsystems/audit from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/auth from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/backup from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/cron from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/dflt_users from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/lp from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/mem from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/sysadmin from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/terminal from root to auth (y/n)? y
Change owner of /etc/auth/subsystems/uucp from root to auth (y/n)? y

Notice that /usr was one of the fixed directories. I do hope this was it.

Thank you!

 

[KenCunningham]

Looks like it probably is - all SCO systems here have /usr as 775 perms. Good work fellas!

 

[josel]

OK, this is my latest accessment of what can be the problem:
I am having problems with mail/sendmail. Out of 150+ users, only a handfull of them end-up with permission problems ... This morning, I received the call from one of them; I decided to look for more users to sort out how many more and who are they.

I then checked for file content in their $HOME directories and found nothing with matching date stamps. I then went to /usr/spool/mail and BANG! there it is. The same users with permission problems have mail queued.

My guess is that since I have manually set users' $HOME directory to 755, not 0775, if mail/sendmail failed as it attempted to write dead-letter to $HOME directory, it changed permission to 666 in order to be able to write dead-letter file ...

This may sound wild and far fetch, but mail queued is the ONLY thing I've found between the handfull of users reporting this problem.

The question is, why would mail/sendmail change permission on $HOME directory thus leaving such potential security breach?

Thank you all for your assistance, I will keep you posted if changing permission to 0775 from 755 makes a difference!

Jose Lerebours