Changes to fstab file causes server to crash

[Tania Paulse]

Hello

We have attempted to make certain changes to the fstab file without success.

The original file was:

/dev/vg00/lvol4 / vxfs delaylog 0 1
/dev/vg00/lvol1 /stand hfs defaults 0 1
/dev/vg00/lvol5 /home vxfs delaylog 0 2
/dev/vg00/lvol6 /opt vxfs delaylog 0 2
/dev/vg00/lvol7 /tmp vxfs delaylog 0 2
/dev/vg00/lvol8 /usr vxfs delaylog 0 2
/dev/vg00/lvol9 /var vxfs delaylog 0 2
/dev/vg00/lv_crash /var/adm/crash vxfs largefiles,delaylog 0 2
/dev/vg_swap/swap1 / swap pri=0 0 0
/dev/vg_misc/omniguard /opt/omniguard vxfs delaylog 0 2
/dev/vg_misc/ctsagent /app/ctsagent vxfs delaylog 0 2
/dev/vg_misc/sec /app/sec vxfs delaylog 0 2
/dev/vg_misc/patrol /app/patrol vxfs delaylog 0 2
/dev/vg_misc/bmcdata /app/bmcdata vxfs delaylog 0 2
/dev/vg_misc/controlm_server /app/controlm_server vxfs delaylog 0 2
/dev/vg_misc/controlm_agent /app/controlm_agent vxfs delaylog 0 2
/dev/vg_misc/oracle /app/oracle vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/oracle_920 /app/oracle/product/9.2.0 vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/oracle_admin /app/oracle/admin vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/oracntl_1 /mnt/oracle/oracntl_1 vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/oracntl_2 /mnt/oracle/oracntl_2 vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/oracntl_3 /mnt/oracle/oracntl_3 vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/oracle_export /mnt/oracle/export vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/ora_common /app/oracle/product/common vxfs rw,suid,delaylog,largefiles,datainlog 0 2
/dev/vg_misc/cis /opt/CIS vxfs rw,suid,delaylog,largefiles,datainlog 0 2


The security changes made to the file produced the following:

/dev/vg00/lvol4 / vxfs delaylog 0 1
/dev/vg00/lvol1 /stand hfs nosuid 0 1
/dev/vg00/lvol5 /home vxfs delaylog,nosuid 0 2
/dev/vg00/lvol6 /opt vxfs delaylog,ro 0 2
/dev/vg00/lvol7 /tmp vxfs delaylog,nosuid 0 2
/dev/vg00/lvol8 /usr vxfs delaylog,ro 0 2
/dev/vg00/lvol9 /var vxfs delaylog,nosuid 0 2
/dev/vg00/lv_crash /var/adm/crash vxfs largefiles,delaylog,nosuid 0 2
/dev/vg_swap/swap1 / swap pri=0 0 0
/dev/vg_misc/omniguard /opt/omniguard vxfs delaylog,ro 0 2
/dev/vg_misc/ctsagent /app/ctsagent vxfs delaylog,nosuid 0 2
/dev/vg_misc/sec /app/sec vxfs delaylog,nosuid 0 2
/dev/vg_misc/patrol /app/patrol vxfs delaylog,nosuid 0 2
/dev/vg_misc/bmcdata /app/bmcdata vxfs delaylog,nosuid 0 2
/dev/vg_misc/controlm_server /app/controlm_server vxfs delaylog,nosuid 0 2
/dev/vg_misc/controlm_agent /app/controlm_agent vxfs delaylog,nosuid 0 2
/dev/vg_misc/oracle /app/oracle vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/oracle_920 /app/oracle/product/9.2.0 vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/oracle_admin /app/oracle/admin vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/oracntl_1 /mnt/oracle/oracntl_1 vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/oracntl_2 /mnt/oracle/oracntl_2 vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/oracntl_3 /mnt/oracle/oracntl_3 vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/oracle_export /mnt/oracle/export vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/ora_common /app/oracle/product/common vxfs rw,delaylog,largefiles,datainlog,nosuid 0 2
/dev/vg_misc/cis /opt/CIS vxfs suid,delaylog,largefiles,datainlog,ro 0 2

The server then refused to boot-up. Could you please provide me with an idea as to why this could be occuring?

We have made similar changes on other platforms without problems.

[Mark Grant]

I think you need to gt the machine up to find out what the problem is.

If it isn't already up, bring it up in single user mode and have a look at /etc/rc.log to see if we can find out at what point it has it's problem.

[Jean-Luc Oudart]

Also,

you may want to boot in single mode aand mount these fs one by one with the new options

Regards,
Jean-Luc

[Shaikh Imran]

Hi,
If i have observed properly than
/stand filesystem is mounted with nosuid option rather than the defaults as in the original fstab file.

Boot the system in singel user mode and change it and try to boot.

Regards,

[Thierry Poels_1]

hi,

if "nosuid" is added to the mount options with a blindfold on then you're asking for trouble.

nosuid disables set-user-ID execution.

Check your file systems for binaries with set-user-ID set before disabling it. It seem you currently blocked $ORACLE_HOME/bin/oracle from being executed as Oracle.

regards,
Thierry.

[Mark Grant]

I could be wrong but I don't think the setuid thing should be the problem. There aren't normally any setuid progs in /stand and there isn't the nosuid on the "/" filesystem in the new fstab.

[Bill Hassell]

I think it would be very important to define 'refuse to bootup'. If you mean that the kernel doesn't get loaded (the 3 binary numbers at the beginning of bootup) then fstab isn't involved. If you mean that there are errors during filesystem mount (early in the kernel startup) then those should be addressed based on the individual entry. All the startup errors are logged in /etc/rc.log. Perhaps the error messages will help.

nosuid should be applied to EVERY mountpoint (including /stand) except /usr and /opt because no executable programs, especially SUID programs, should exist on any other mountpoint. /stand has a couple of *.mk files that are executable but they do not have the SUID bit set.

However, I believe your errors are in read-only attributes for /usr and /opt (and possibly /opt/omniguard and /opt/CIS). Both /usr and /var will need to be writable for the system to function. The ro option is global and not even root can override this setting.

[Jean-Luc Oudart]

I think the binary oracle needs the suid
$ORACLE_HOME/bin/oracle

Regards,
Jean-Luc

[Cheryl Griffin]

Boot single and check out /etc/shutdownlog to see why the server crashed.