SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart]

[Gary Winiger]

> 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?

> 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?

> 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?

> 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?

	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.

> 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?

>                 <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?
> -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?
	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?  What's the patchrm story?

> 	iscsitgt.xml:
> 		Add RBAC authorization for action_authorization and
> 		value_authorization.

	Are there no modify_authorization's needed?

> 	auth_attr:
> 		Add authorization attributes:
> 		   solaris.smf.value.iscsitgt
> 		   solaris.smf.read.iscsitgt

	Missing here would seem to be solaris.smf.manage.iscsitgt

> 	prof_attr:
> 		Add iSCSI Target Management rights profile.

	See above.  Perhaps more than one profile is desired.

> 	iSCSI Target Daemon:
> 		Add SCF functionality and RBAC authorization.

	What is this saying the daemon is doing with authorization?

>     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?

>     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 and
	the CLI itself is Evolving?  Or is it saying something
	else?

>     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?
	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.

	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?

Gary..