[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