File Permissions in OMSA 5.2 (SLES10)

[Michael E Brown]

On Wed, Jul 04, 2007 at 02:25:21PM +0100, David Carter wrote:
> 
> After installing OMSA 5.2 on a number of Poweredge 2950s running SLES 10, I 
> seem to have ended up with a collection of world writable files:

I've reported these to the OMSA developers. Below is what they told me.

>    /var/log/TTY_00000000.log

Should be fixed $NEXTRELEASE.

>    /var/log/ssevt.log

Should be fixed $NEXTRELEASE.

>    /opt/dell/srvadmin/oma/log/cachecfg.txt

Should be fixed $NEXTRELEASE.

>    /opt/dell/srvadmin/oma/.omaipc
>    /opt/dell/srvadmin/shared/.ipc/.sharedipc

These two files are only used to synchronize between some of the OMSA
processes.

You can chmod them to be not-world-writeable. You will lose the ability
to run any 'omreport' or 'omconfig' commands except as root-user or
root-group.

These files are never read or written to by OMSA, they are only used for
fcntl.

These are planned to go away in $NEXTRELEASE in favor of sockets.


> /opt/dell/srvadmin/oma/.omaipc is part of the srvadmin-omacore RPM. The 
> other 4 files seem to be created as the various monitoring packages start.
>
> Is there an easy way to fix the permissions from within OMSA? These files 

No.

> really shouldn't need to be world writable. Two of the files:
> 
>    /opt/dell/srvadmin/oma/log/cachecfg.txt
>    /var/log/TTY_00000000.log

Looks like bugs. They are logged and should go away $NEXTRELEASE.

> 
> get rotated when OMSA starts, so a simple chmod doesn't help. In fact a 
> chmod seems to stop some of the daemons from starting.
> 
> My fallback would be to restrict access to /var/log and /opt/dell. The CLI 
> is the only part of OMSA that I need.

That is a satisfactory solution. (see caveat above.)
--
Michael