Glad to hear that Ken, thank you! >> these devices would simply not register a callback which should result in an >> immediate response to the security manager.
Looks like I wasn't clear - the back compat behavior I maintained is exactly what you said in the line I copied/pasted above. Nothing more and nothing less - I believe. Let's try to get consensus on this proposal in the next WG meeting. Thanks, Dan From: Swinson, Ken [mailto:[email protected]] Sent: Tuesday, February 9, 2016 4:22 PM To: Daniel Mihai <[email protected]>; [email protected]; Lioy, Marcello <[email protected]>; [email protected]; Dominique Chanet (QEO LLC) <[email protected]>; Josh Spain <[email protected]>; [email protected] Cc: Dave Thaler <[email protected]>; Arvind Padole <[email protected]> Subject: RE: proposal for 16.04: add StartManagement/EndManagement notifications, sent by Security Manager to the app being managed Hi Dan, I think reducing code paths to reduce test efforts, reduce backwards compatibility testing, and future code maintenance are good reasons to not put effort into special casing security 2 support for 15.09. I suspect that the manifest change that you will be proposing will likely break backwards compatibility anyway so why worry about backwards compatibility for Start/StopManagement functionality. Regarding simply devices that do not need the functionality; these devices would simply not register a callback which should result in an immediate response to the security manager. I like the proposal. Ken From: Daniel Mihai [mailto:[email protected]] Sent: Monday, February 08, 2016 3:27 PM To: Swinson, Ken; [email protected]<mailto:[email protected]>; Lioy, Marcello; [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC); Josh Spain; [email protected]<mailto:[email protected]> Cc: Dave Thaler; Arvind Padole Subject: RE: proposal for 16.04: add StartManagement/EndManagement notifications, sent by Security Manager to the app being managed Thanks Ken! In my current proposal, StartManagement is synchronous, and the target app must be ready to receive new settings immediately - as soon as its StartManagement callback returns. BTW, the proposed implementation is: - For SCL: https://git.allseenalliance.org/gerrit/#/c/6723/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.allseenalliance.org%2fgerrit%2f%23%2fc%2f6723%2f&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c42744fd58ce143d0d0ee08d331b02e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WadHrrGQcrBOkLXxS8UShT4l38jo5X1IzB2050PTef4%3d> - For TCL: https://git.allseenalliance.org/gerrit/#/c/6717/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.allseenalliance.org%2fgerrit%2f%23%2fc%2f6717%2f&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c42744fd58ce143d0d0ee08d331b02e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FxFmc%2fqzAVs1p0vU1mNkos5FbpfuCCxk7sbrlhl8K9s%3d> I agree that we don't have to be backwards compatible. However, for this particular proposal, some folks argue that perhaps a very simple device doesn't need a StartManagement callback at all. For example: A very simple com.Contoso.Clock Producer device that sends out the time of day, as sessionless signal, as a result of an incoming GetTimeOfDay sessionless signal. If the device fails to send the time of day, because the Admin is making Manifest changes, that device could silently ignore the PERMISSION_DENIED error, and just wait for the next request from a Consumer. This simplistic Clock Producer doesn't need a StartManagement callback, so the 15.09 org.alljoyn.Bus.Security.ManagedApplication functionality is good enough for it. Therefore, I haven't found a good reason to break compatibility with their existing 15.09 functionality. A device/app just gets additional benefits if it is StartManagement/EndManagement-aware. Dan From: Swinson, Ken [mailto:[email protected]] Sent: Monday, February 8, 2016 3:10 PM To: Daniel Mihai <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Lioy, Marcello <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC) <[email protected]<mailto:[email protected]>>; Josh Spain <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: Dave Thaler <[email protected]<mailto:[email protected]>>; Arvind Padole <[email protected]<mailto:[email protected]>> Subject: RE: proposal for 16.04: add StartManagement/EndManagement notifications, sent by Security Manager to the app being managed Hi Dan, Would the target app inform the security manager when it is ready to receive the new settings receipt of StartManagement? In general, if we replace or deprecate functionality that was provided as developer preview then we should not expend effort to assure backwards compatibility with it. Ken From: Daniel Mihai [mailto:[email protected]] Sent: Friday, February 05, 2016 3:33 PM To: [email protected]<mailto:[email protected]>; Lioy, Marcello; [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC); Swinson, Ken; Josh Spain; [email protected]<mailto:[email protected]> Cc: Dave Thaler; Arvind Padole Subject: proposal for 16.04: add StartManagement/EndManagement notifications, sent by Security Manager to the app being managed We discussed several weeks ago in the Core WG meeting, in the context of ASACORE-2599, that: Security Manager changing settings without first notifying the target app can result in random errors being experienced by the target app - e.g. for an already-existing session. Random errors are hard to handle properly by the target app. To help improve that behavior, I propose adding new StartManagement & EndManagement methods to the org.alljoyn.Bus.Security.ManagedApplication interface: 1. A Security Manager should call StartManagement before starting to make disrupting settings changes to the target app. 2. As a result, the target SCL app receives a PermissionConfigurationListener::StartManagement callback. a. TCL apps get similar but TCL-style callbacks for StartManagement & EndManagement. 3. Using that callback, the app should get ready for disruptive changes - e.g. perhaps by gracefully shutting down its active sessions. 4. The Security Manager should call EndManagement after finishing its work. 5. The target app receives PermissionConfigurationListener::EndManagement callback, and can resume its normal functionality. 6. For compatibility with 15.09: a. Calling StartManagement & EndManagement from a Security Manager is not mandatory. A Security Manager that doesn't call these new methods gets the same behavior it used to get in 15.09. b. The app doesn't have to set-up StartManagement & EndManagement - it can choose to ignore these notifications at its own risk. The app gets the 15.09 behavior if it ignores these callbacks. Please speak up with any thoughts or questions. Thanks, Dan
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
