Hey fellow bit pushers,
I have been seeing an odd problem on a few of my systems and was wondering if any of you have seen it on your systems and possibly know why it happens.
We have a custom model script for a printer on our systems. This model script is just a standard ksh script but it calls a few compiled c programs to parse the -o options from lp as well as parse the c* file in /var/spool/lp/request/<printer> to find the name of the original file being printed. Some times on some of our systems after a reboot, the permissions of these binaries have been set from 550 to 440. The permissions on the actual model script in all it's various locations remains unchanged. It's like something is looking at our model script, finding all the binaries we are calling, and then chmoding them. This does not happen on all our systems and does not happen consistantly. As a work around I have written a script in /sbin/rc2.d to chmod them back to 550 after a reboot.
I have racked my brains out and HP wasn't any help (they tried hard though and I give them credit for that). I have been through all startup and shutdown scripts to no avail. I have been through every log on the system I could find and I can find no hint as too why this happens. I guess it might just be Unix Voodoo.
Thanks for any suggestions or answers,
Tony

Lose that script that chmods them back. Instead write a script that does a date and then a ls -l on the binaries and appends the output to a special log file. Have this script run as the first and last item on both startup and shutdown on all the rc?.d directories.

After you do this and after it happens again, you will know, say, that it happens during the K* scripts in /sbin/rc1.d (or whatever). So next you put the script at 3 or 4 points in this sequence of scripts. Eventually you will have the name of the script that is doing this.

Also remember that after it happens, you can type:
ls -lc binary
and get the exact time that it was chmod'ed. This may help track it down.

Where do the binaries reside? Who owns them? Which version of HP-UX? What output do you get from "grep chmod /sbin/init.d/*"?

Thanks for reply. Unfortunately I can't afford to not have my chmod script run since this is a prod box and it needs to be functional after a reboot, or in a worst case, after a crash. I will, however write a script like you mentioned and put it in the rc?.d directories between each of the other scripts since I can't afford to keep rebooting. I will have to catch it in 1 try, hopefully. I have been through init.d already, but here is the output if you want to see it:

/sbin/init.d/clean_tmps: chmod 1777 /tmp
/sbin/init.d/hpfc: chmod 666 /dev/lan$CARD_INSTANCE
/sbin/init.d/hpfcms: chmod 666 /dev/fcms${inst}
/sbin/init.d/inetsvcs: chmod 444 $file
/sbin/init.d/maclan_init: chmod 600 /dev/lan$INSTANCE_NUMBER
/sbin/init.d/nfs.core: chmod 755 /etc/net
/sbin/init.d/nfs.core: chmod 755 /etc/net/$i
/sbin/init.d/nfs.core: chmod 644 $ETC_NET/$j/$i
/sbin/init.d/nfs.core: /usr/bin/chmod 644 /etc/net/$i/hosts
/sbin/init.d/nfs.core: chmod 644 /etc/net/$i/hosts
/sbin/init.d/ppp: mknod $dev c $MAJOR $m; chown root $dev; chmod 600 $dev
/sbin/init.d/ppp: mknod $dev c $MAJOR $n; chown root $dev; chmod 600 $dev
/sbin/init.d/ppp: mknod $dev c $MAJOR $m; chown root $dev; chmod 600 $dev
/sbin/init.d/splex: chmod 0664 /dev/splex > /dev/null 2>&1
/sbin/init.d/splex: chmod 0664 /dev/splexc > /dev/null 2>&1
/sbin/init.d/swagentd: chmod 600 $acl_path

Nothing unusual as far as I can tell. The inetsvcs was suspect breifly becuase of the 444. We see this on both HPUX 10.20 and 11, both 32 bit. Any other thoughts or ideas are more then welcome.
Thanks,
Tony