[ofa-general] Re: [PATCH] saquery: --smkey command line option

Hal Rosenstock hrosenstock at xsigo.com
Tue May 27 04:33:56 PDT 2008


On Tue, 2008-05-27 at 13:33 +0300, Sasha Khapyorsky wrote:
> On 05:52 Fri 23 May     , Hal Rosenstock wrote:
> > 
> > But can be protected by other weak access control currently and perhaps
> > more in the future.
> 
> OpenSM console is not a great example IMO - OpenSM doesn't need to issue
> SA queries against itself.

There's no reason it couldn't though rather than go after internal data
structures.

> > New commands which require trust can utilize SMKey
> > without it being specified (at least for OpenSM), no ?
> 
> Maybe yes, but could you be more specific? Store SMKey in read-only
> file on a client side?

Treat smkey as su treats password rather than a command line parameter
is another alternative.

> > > And what about diagnostics when other SMs are used?
> > 
> > I think there's a problem here in a trusted environments given the
> > approach taken as I've stated in the past but seems to have been
> > forgotten. The more trust the less the current diag strategy fits.
> > 
> > Are you also going to be proposing exposing MKeys too once MKey
> > management is supported by OpenSM/other SMs ?
> 
> I don't have any M_Key manager implementation details, 

There have been no details as yet but one can readily extrapolate the
same issue from the spec. (The issue actually goes further for MKey
IMO).

> but hope it will not needed.

I believe it is on the OFED 1.4 list.

> I'm not proposing to expose SM_Key, just added such option where this
> key could be specified.

How is that not exposing it ?

-- Hal

>  So: 1) this is *optional*, 2) there is no
> suggestions about how the right value should be determined.
> 
> Sasha




More information about the general mailing list