Starting SAM changed the device files permissions

[Solmaz]

Dear All,
HP-UX 11.23 environment including Oracle RAC 10g .
Once the SAM executed , permission of device files related to Oracle RAC (/dev/rdsk/) were changed and Database was stopped.
What is the background processes of SAM?
Is it trying to check/change permissions to default mode (bin:sys)?

[Matti_Kurkela]

Please read the SAM logfile (/var/sam/log/samlog) to see the exact commands SAM used.

SAM will normally run "insf", but that should not change the permissions of existing devices.

Perhaps something caused SAM to run "insf -e", which will re-create *all* device files, using default permissions.

MK

[Solmaz]

Hi Matty,

The SAM log is normal. (ioparser.sh , ioscan , ...)

Before running SAM , device files had been existed with proper condition and permissions. and running SAM changed the permissions suddenly.
The event time of Database Failure (permission error on Disks) and running SAM are exactly equal together.
Any idea?

[Ismail Azad]

Hi,

Please check this thread...
http://h30499.www3.hp.com/t5/System-Administration/Serial-Com-Port-1-Device-File-Permissions-Auto-Changed/m-p/3346922#M191728

I normally never quote others or provide links but this is a fabulous piece of information.

" This is normal behavior for a port that is running getty or a getty-like process. THe sequence is that the port is initially owned by root with permissions 622; upon login (which initially runs as uid 0) the ownership is changed to the current user. As soon as the session is finished, another getty is spawned and the process repeats. If you need to change this behavior, you must substitute your own getty-like process for the one currently specified in /etc/inittab for this port. "respawn" instructs the system to start a new process when the old one dies OR change the "respawn" to "off" and assume control of the port through your own software. Another option is to use a process which opens the port, sets initial modes and ownership, baudrate, etc. and then
waits forever. In this case, the process would never terminate so your 666 permissions would remain intact. As long as you are running getty or uugetty, the behavior will be just what you observe and that is both normal and desirable from a security standpoint."

- 'MR. A Clay stephenson'!!!!

Regards
Ismail Azad

[Dennis Handly]

>Ismail: I normally never ... provide links

(Nothing wrong with links, provided they don't go stale. :-)

>"This is normal behavior for a port that is running getty

I don't think this would occur for /dev/rdsk/.