IZ2228: Installation fails on extra-secure servers

[mathog]

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=2228]

        Issue #:      2228             Platform:     All      Reporter: mathog (mathog)
       Component:     gridengine          OS:        Linux
     Subcomponent:    install          Version:      6.0u10      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    dom (dom)
      QA Contact:     dom
          URL:
       * Summary:     Installation fails on extra-secure servers
   Status whiteboard:
      Attachments:

     Issue 2228 blocks:
   Votes for issue 2228:


   Opened: Mon Apr 2 09:59:00 -0700 2007 
------------------------


Installation of SGE 6.0U10 failed on Mandriva 2006 and the issue was
eventually tracked down to certain directory protections.  Mandriva
comes with a security package called "msec" which among other things
sets the directory protections, and on the machine in question the security
level was 4 (out of 5), which is more secure than the typical server, as
this machine normally has no interactive users.  As a result of these
directory protections certain "rm -rf" commands in the installation script
failed and the installation aborted.   (Note also that `which rm` would
also have failed.)

To work around this I did the following (assumes perm.local does
not already exist):

% cd /etc/security/msec
cat >perm.local <<EOD
/                                               root.adm                755
/bin/                                           root.adm                755
/usr/                                           root.adm                755
/usr/*                                          root.adm                755
/usr/X11R6/                                     root.xgrp               755
/tmp/                                           root.adm                1777
EOD
% msec

This reset the protections on the directories listed from 751 to 755, and from
1773 to 1777.  After this the SGE install completed successfully.  [Note,
these settings are probably NOT required for SGE to run, only for it to be
installed.  I had been running 5.3p6, copied from an earlier system, for
7 months with the older protections with no issues.]

In any case, since head nodes on clusters are frequently set up with extra
security, so that this situation might occur on other machines, it would
probably be a good idea to have the SGE install script check the directory
protections on at least /tmp, /usr/bin, and /bin to verify that the script
will be able to execute.  The script already has a section which checks/sets the
protections on its own files, and since the script had not yet failed by that
point, that's a logical place to add this.  It would be much better to be
notified before the fact that "this installation cannot proceed because the
protection on /tmp is 1773, it must be 1776", than to run into the
mysterious message which appeared on my system, replicated with discrete
commands here:

 % su - sgeadm
 % cd /tmp
 % mkdir foo2
 % touch foo2/blah
 % ls -al foo2
 total 8
 drwxrwxr-x   2 sgeadm sge 4096 Mar 30 08:11 ./
 drwxrwx-wt  10 root   adm 4096 Mar 30 08:11 ../
 -rw-rw-r--   1 sgeadm sge    0 Mar 30 08:11 blah
 % rm -rf /tmp/foo2
 rm: cannot get current directory: Permission denied