> Gary Winiger wrote:
> >> Gary Winiger wrote:
> >>
> >>>> Summary of the concerns and proposed solutions for the PSARC 2007/414:
> >>>>
> >>>> Concern: Does clear text CHAP secret provides enough security?
> >>>>
> >
> > It seems that this project is being factored to bypass this issue.
> > See the project teams response below.
> > Is the project complete without a CHAP secret?
> >
> No, we need to move all configuration data to SCF including CHAP secrets.
Then what do you mean by factored to bypass this issue.
> >>>> Concern: The iSCSI target manifest does not comply with SMF
> >>>> authorization.
> >>>> Proposal:
> >>>> -We will add action_authorization and value_authorization to the
> >>>> manifest to make
> >>>> it SMF authorization compliant.
> > At the code review level, I'm not sure
> > 2. Iscsitgt service manifest
> > will do what you want it to do. Please have the SMF folk code
> > review your service manifest.
> >
> Yes, this will require code review from the SMF folk.
>
> Since the original PSARC only address the conversion of configuration to
> SCF data, the issue of RBAC
> came up during this PSRAC exchange, I'm requesting to open a P3 CR to
> address the RBAC issue, this
> should not affect the security issue with the implementation of PSARC
> 2007/177, this will speed up the
> putback of the SCF converson that the FishWorks team is waiting for.
Boy and I confused. RBAC has been part of Greenline since day 0.
The policy is articulated in a SAC policy that predates this case.
IMO, no, adding RBAC is not a P3 bug. It is a TCR for this case.
I'm close to derailing as I'm getting more and more confused by
each exchange.
I suggest you work with your case owner and get things straightened
out.
> >>> Some how, I've
> >>> missed the FMRI and man pages documenting it. Shouldn't this
> >>> turn iscsitadm into being completely authorization driven? ;-)
> >>>
> >>>
> >> No authorization is needed for iscsitadm, the cli sends the request to
> >> the daemon and
> >> the daemon verify the user credential. I don't think update to the man
> >> page is needed.
> >>
> >
> > What daemon would that be?
> The iscsitgtd daemon performs all scf operations and verify the data are
> correct, this is the prefer method to
> update the iscsi target configuration.
Huh? The iscsitgtd program updates the repository? Why would that
be? Still more confusion on my part. Certainly if iscsitgtd enforces
authorizations and it will need to comply with the Solaris Audit
policy. See SAC policies.
> > svc.configd is in charge of changing
> > properties and enforcing authorizations for the repository.
> > Without man page updates, how is the admin going to know
> > that the user/role must have the Iscsi Target Management Rights
> > Profile to successfully run iscsitadm?
> >
> We can add the RBAC authorization to the iscsitadm(1M) man pages for the
> RBAC authorization
> putback.
The point is to correctly document the administrative interface,
not to just put up with annoying ARC members ;-)
> >>>> Issues:
> >>>> -The CHAP secret will be put back after PSARC 2007/177 is putback.
> >>>> The PSARC 2007/414 will
> >>>> cover the putback of the CHAP secret at a later time, and no
> >>>> additional case is needed.
> >>>>
> >>>>
> >>> I'm not sure how to read this. Is this accepting a case dependency
> >>> on 2007/177? Or is it saying that a two phase project is being
> >>> requested. Phase 1 without CHAP, phase 2 after 177 with CHAP.
> >>>
> >>>
> >> We are requesting to make this a 2 phase project, and we will provide
> >> all the documents to
> >> address both phases. The 2nd phase will accept the 2007/177 dependency.
> >>
> >
> > Is the project complete in phase 1?
> No.
> > Is the intent that this
> > ARC case cover both phases?
> Yes, the reason for the 2 phases was because of the dependency on PSARC
> 2007/177.
> > Why is a phased approach needed or
> > desirable to the administrator?
> >
> It's probably not desirable, but without knowing when 2007/177 will be
> approve, that how we
> scheduled the project.
Schedule is not an architectural consideration. 2007/177 has
been approved. It is out for code review. If you have schedule
issues, you need management to coordinate the projects.
So I'd say from this interchange that this case has a dependency on
2007/177 and must deliver a full case.
Please work with your case owner to come up with a spec for this
case that clears up the issues raised.
Gary..
