Reset permisions on system files

[Alan Moreland_2]

A rogue process has changed the permissions through our HPUX 10.20 to be 750. Is there anyway I can reset the permissions to their default without having to do a restore?

[Dan Am]

no way that I know of. if you have disk space and don' want to keep your files you can restore into a diectory and then shellscript the thing to compare and set the permissions.

[Nancy Hubert]

Hi,

unfortunately there is no tool to restore the default permissions on a system, I don't know if the changes affect the entire system (all the directories and files) if it is the case then you will have to restore or if you have a similar system you can rcp with -p option
from the remote system some of the files and directories.

If you do a rcp, don't copy the configuration files.

Hope this helps.

[Andreas Voss]

Hi,

i've looked for something to do this and have found that under /var/adm/sw/products files with the name INFO have the contents of the installed files/dirs with their permission modes.
I wrote a script, that read these files and produces another script (perm_reset.sh) with the chmod commands.
Just running the script perm_reset.sh should correct many system files/dirs.

Hope that helps.

Andrew

[Timothy Czarnik]

Alan,

If you have a recent make_recovery, you could always use that to get the root VG perms back. If you didn't want to actually use the make_recovery to recreate the root VG, you could use TAR to extract files from the tape to a different directory, then compare the perms (mt -t fsf 1 --- then its just tar from there). Ugly, I know... If you have perms problems with files outside of the root VG, you can get perms info from backup software that you use. Very manual. Again, very ugly.

Good luck!

-Tim

[Cheryl Griffin]

Wait!! Do not restore just yet.
Try swverify. It wont change the permissions to what they were but they will check if they are not the defaults.

For example:
# swverify -v check_permission=true SystemAdmin

will check that the permissions for the SAM fileset are correct.

[Alan Moreland_2]

Thanks for the replies.
I ran perm_reset.sh and SAM is now functioning but I'm getting the following error :-

Sep 22 10:14:07 zireh500 sendmail[17519]: KAA17513: SYSERR(root): savemail: cannot save rejected email anywhere

[Cheryl Griffin]

Alan,
The savemail error is a common problem when your sendmail version does not match the sendmail configuration file.

Check the following:
# sendmail -di (debug mode, displays the version)
# grep DZ /etc/mail/sendmail.cf

If the two versions do not match:
# grep DZ /usr/newconfig/etc/mail/sendmail.cf
If this version matches your sendmail -di version:
# mv /etc/mail/sendmail.cf /tmp/sendmail.sav
# cp /usr/newconfig/etc/mail/sendmail.cf /etc/mail/sendmail.cf

If you had any custom configuration in the old version (/tmp/sendmail.sav), add them to the new file.

Stop and restart sendmail:
# /sbin/init.d/sendmail stop
# /sbin/init.d/sendmail start

Loading the sendmail patch will update the /usr/newconfig/etc/mail/sendmail.cf instead of /sendmail.cf (because this is a custom file).

[Andreas Voss]

Hi,

To solve the problem check permissions and ownerships on /var/mail

drwxrwxr-x 2 bin mail

and on the single mailboxes, e.g. root /var/mail/root and user /var/mail/user

-rw-rw---- 1 root mail /var/mail/root

-rw-rw---- 1 user mail /var/mail/user

Furthermore allow savemail to write to $HOME/dead.letter and /var/tmp/dead.letter: Set permissions to 777

Regards