SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart]
tim szeto
Tim.Szeto at sun.com
Wed Sep 12 13:51:27 PDT 2007
This is a correction to my previous response.
See CORRECTION; in email
tim szeto wrote:
>
>
> Gary Winiger wrote:
>>> I've restarted the timer on this fast-track case; it's now set to
>>> 09/14/2007.
>>>
>>
>> Sigh. I'm getting quite frustrated with this review. Somehow
>> when I believed the project team and case owner understood the
>> issues, I thought I'd see that more clearly reflected in the
>> updated materials. Maybe I'm misreading or just being too picky.
>> I've certainly missed seeing how the CLI commands end up
>> at svc.configd in the CLI callers context.
>>
>> <frustrated plea>
>> Can we just get it right? Is that too much to ask? I thought I
>> gave the project team all the things to say and write in the
>> telecon. I don't see it reflected in the updated spec. Does the
>> smf project team agree that this will all work as specified?
>> Please oh please explain why
>> http://opensolaris.org/os/community/arc/policies/SMF-policy/;jsessionid=3EC010F3467A31CCC9E5BD6C4C2FEF51
>>
>> is so hard to understand. I want to make it clear. See below
>> for the detailed context.
>> </frustrated plea>
>>
>>
>>> -rw-rw-r-- 1 markcarl sacmail 6459 Sep 10 15:23 scf_design
>>>
>>
>>
>>> High Level:
>>>
>>
>>
>>> -The CLI still uses the door interface to the daemon, the mgmt
>>> interfaces are used to create incore database and then use the
>>> mgmt_scf interfaces to create/modify/delete the SCF database.
>>>
>>
>> How does this work so that svc.configd enforces policy based
>> on the caller of the CLI and audits these changes correctly?
>>
> We will have the svc.configd authenticate the CLI user.
>>
>>
>>> Issue
>>> ======
>>> The property CHAP SECRETS is converted to SCF after PSARC 2007/177
>>> is putback.
>>>
>>
>> Again, does this mean that this case is dependent on 177
>> and will not putback before it, or is this saying something
>> else? Why is this an issue and not a case dependency?
>>
> PSARC 2007/177 is a dependency, we will not putback until PSARC
> 2007/177 is putback.
>>
>>> 1. Iscsitgt service
>>>
>>> The following authorizations are added to the auth_attr(4) file:
>>>
>>> solaris.smf.action.iscsitgt:::Action ISCSITGT
>>> Service::help=SmfIscsitgtStates.html
>>> solaris.smf.value.iscsitgt:::Change ISCSITGT Service
>>> Properties::help=SmfValueIscsitgt.html
>>> solaris.smf.read.iscsitgt:::Read Protected ISCSITGT
>>> Properties::help=SmfReadIscsitgt.html
>>>
>>
>> Code review level. Missing from here is the manage authorization.
>> Please oh please show md with anything of the form
>> solaris.smf.action
>> is part of the policy?
>>
> Yes, manage_authorization will be added.
CORRECTION: The value of 'solaris.smf.action.iscsitgt'
will be changed to 'solaris.smf.manage.iscsitgt'
>>
>>
>>> The following profile is added to the prof_attr(4) file:
>>>
>>> Iscsi Target Management:::iSCSI Target
>>> Management:help=RtIscsitgtMngmnt.html:auths=solaris.smf.manage.iscsitgt,solaris.smf.value.iscsitgt,solaris.smf.read.iscsitgt
>>>
>>>
>>
>> Does a single profile really make sense? Is it expected that
>> there would be no separation of duties between admins who can
>> create new targets, or delete targets or set passwords and
>> those who can modify existing target values?
>>
> A single profile is sufficient. But if deemed best to have an
> additional profile, we will add additional
> profiles.
>> Did the SMF team say that no modify_authorization was needed?
>> Remember the whole point is that an admin with the appropriate
>> Rights Profile can run the CLI. See above question of how
>> the daemon works.
>>
> The modify_authorization is needed for creation of new target.
>>
>>> 2. Iscsitgt service manifest
>>>
>>> <property_group name='iscsitgt' type='application'>
>>> <propval name='action_authorization' type='astring'
>>> value='solaris.smf.action.iscsitgt' />
>>>
>> ^^^^^^
>> Gosh doesn't the sfm policy say manage? And wouldn't
>> this be in the general/framework property group?
>>
> Yes, it should be solaris.smf.manage.iscsitgt.
>>
>>> <propval name='value_authorization' type='astring'
>>> value='solaris.smf.value.iscsitgt' />
>>> <!-- To read and modify protected properties -->
>>> <propval name='read_authorization' type='astring'
>>> value='solaris.smf.read.iscsitgt' />
>>> </property_group>
>>>
>>
>> What does the smf project team have to say about this?
>> Shouldn't value and read authorizations be part of the PG
>> that they affect?
>>
> I consulted with the SMF team, the read_authorization and
> value_authorization
> properties are needed in the PG.
>>> -rw-r--r-- 1 ts143224 sacmail 5160 Sep 10 15:21 func_spec
>>>
>>
>>
>>> 1.3 Changes From the Previous Release
>>>
>>> This is a change from PSARC 2005/441. This will be a micro/
>>> patch release. The changes are moving persistent data stored
>>> in files to the SMF repository. The persistent data are project
>>> private and managed by the iSCSI Target daemon.
>>>
>>
>> How does this release binding align with
>>
>>> 2.4 Compatibility and Interoperability
>>>
>>> 2.4.7 Compatibility with Earlier and Future Releases
>>>
>>> There is no changes to the interface (iscsitadm(1M)).
>>>
>>> The persistent data will be converted from XML to
>>> SCF upon this upgrade. After the upgrade, the persistent
>>> data cannot revert back to the XML format.
>>>
>>
>> and the requirement that patches be able to be backed out?
>>
> When the patch is backed out, the old configuration will be restore.
>> Does anyone actually care that this doesn't appear to be
>> able to be backed out? Or upon upgrade do you keep all the
>> old configuration files?
> We backup the old configuration files.
>> What's the patchrm story?
>>
> We will restore the old configuration file with patchrm.
>>
>>> iscsitgt.xml:
>>> Add RBAC authorization for action_authorization and
>>> value_authorization.
>>>
>>
>> Are there no modify_authorization's needed?
>>
> modify_authorization is needed.
>>
>>> auth_attr:
>>> Add authorization attributes:
>>> solaris.smf.value.iscsitgt
>>> solaris.smf.read.iscsitgt
>>>
>>
>> Missing here would seem to be solaris.smf.manage.iscsitgt
>>
> solaris.smf.manage.iscsitgt is needed.
>>
>>> prof_attr:
>>> Add iSCSI Target Management rights profile.
>>>
>>
>> See above. Perhaps more than one profile is desired.
>>
> See response above.
>>
>>> iSCSI Target Daemon:
>>> Add SCF functionality and RBAC authorization.
>>>
>>
>> What is this saying the daemon is doing with authorization?
>>
> See above on how we do this architecturally.
>>
>>> 1.5 Related Projects
>>>
>>> 1.5.1 Dependencies on Other Sun Projects
>>>
>>> PSARC 2007/177 smf(5) enhancements for storage of
>>> sensitive properties
>>>
>>
>> Is this saying that isn't an issue as seemed to be
>> stated in smf_design?
>>
> PSARC 2007/177 is a dependency
>>
>>> 2.2 Interfaces
>>>
>>> The interface is Project Private and Evolving. This
>>> interface is iscsitadm and iscsi target daemon.
>>>
>>
>> I'm not sure what is being stated here, is this saying
>> the interface between the CLI and the daemon is PP
> The interface between the daemon and CLI is PP.
>> and
>> the CLI itself is Evolving? Or is it saying something
>> else?
>>
> We are not changing the interface classification of the CLI.
>>
>>> 2.7 Security
>>>
>>
>>
>>> Issue:
>>> RBAC authorization
>>>
>>> Solution:
>>> We propose the following RBAC authorizations for managing
>>> iSCSI Target properties (auth_attr(4)):
>>>
>>
>> Reitterating from above. Is there no need for a
>> modify_authorization to be specified?
>>
> modify_authorization is required
>> Has this been prototyped and an admin with just the
>> specified Rights Profile can effectively do things?
>> N.B. That same admin should be able to do the very same things
>> with svcadm and svccfg. If they can't I fear there's something
>> not right.
>>
> We agree this architectural approach.
>> Did I miss how the CLI enables the service? Or is there some
>> missing documentation to use svcadm enable?
>>
>>
>>> We will add an iSCSI Target Management rights profile to
>>> the iSCSI Target service (prof_attr(4)):
>>>
>>> ISCSI Target Management:::ISCSI Target Management:\
>>> auths=solaris.smf.value.iscsitgt,\
>>> solaris.smf.read.iscsitgt,\
>>> solaris.smf.action.iscsitgt;\
>>>
>> ^^^^^^
>> Don't you mean manage?
>>
> Yes.
>
> -Tim
>
>> Gary..
>>
>
More information about the opensolaris-arc
mailing list