SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart]
tim szeto
Tim.Szeto at Sun.COM
Wed Sep 12 10:15:45 PDT 2007
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.
>
>
>> 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