[ofa-general] Re: [RFC] IB management changes proposal

[Ira Weiny]

On Thu, 26 Apr 2007 19:08:25 +0300
"Michael S. Tsirkin" <mst at dev.mellanox.co.il> wrote:

> > Quoting Hal Rosenstock <halr at voltaire.com>:
> > Subject: Re: [RFC] IB management changes proposal
> > 
> > On Thu, 2007-04-26 at 01:02, Michael S. Tsirkin wrote:
> > > > > There also some few commands (ib*.pl) that are using a file 
> > > > > /tmp/ibnetdiscover.topology.  I suggest /var/cache/ibnetdiscover.topology
> > > > 
> > > > I'm not sure about this one. I need to think about this more.
> > > 
> > > Not sure about the best placement, but surely a predictable name
> > > in a world-writeable directory is a security risk?
> > 
> > Is /var/cache world writeable ? I thought it was just world readable. If
> > this were to be done, I would think the opensm directory underneath this
> > would be more appropriate but I'm not leaning towards doing this since I
> > think the current approach is more flexible and the topology can be
> > supplied to all needed commands/scripts.
> 
> I'm sorry, I'm not familiar with the code.
> I was just saying that using /tmp/ibnetdiscover.topology is clearly
> a security risk since /tmp is world-writeable. Isn't it?
> 

However, I think the risk is pretty low.  The scripts only use this information
to report other information about the subnet.  The only damage would be if an
admin misinterpreted this information and did something bad to the net.
Finally, once the file is created it should have an appropriate umask:

18:05:21 > ls -la /tmp/ibnetdiscover.topology 
-rw-------  1 root root 689670 Apr 24 19:44 /tmp/ibnetdiscover.topology

Therefore from this time forward it can't be modified by users other than root.
(Even a bad umask value set in /var/cache would result in the file being
writable.)

All that being said, generically I think Michael has a point and /var/cache is
probably a better place put it.  Frankly, I never intended the file to be
supplied by an outside program (although when testing the scripts I did do this
from time to time).  /tmp Seemed like a good idea at the time.  ;-)

Ira