Yes we considered that option, too? however, because an ACE can have a period/recurrence, it is not a good idea to simply replace the previous ACE.
For example, it may be that the new ACE is a temporary ?RW? access granted to a subject/resource combination (say just for 1 day or whatever), but there is also a longer-term ACE (say 1 year) granting ?R? access for the same subject/resource. Because of cases like this, it is also beyond the scope of the ACL resource handler to make decisions about replacing/combining/merging/etc. different ACE entries. I really believe that the policy author needs to be responsible for maintaining an accurate set of ACE entries on the Server. Thanks, Nathan From: Ashwini Sharma [mailto:[email protected]] Sent: Thursday, November 26, 2015 1:29 AM To: Heldt-Sheller, Nathan Cc: iotivity-dev; Agrawal, Sachin Subject: RE: [dev] SRM ACL/Policy Engine Agreed that this is beyond the scope of Policy Engine to decide. I guess this can be handled by the ACL resource in PUT handler to keep only the last ACE and removing all the previous ones matching subject and resource. Regards, Ashwini On 24 Nov 2015 23:17, "Heldt-Sheller, Nathan" <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> wrote: Hi Ashwini, Good observation, and yes, this is correct: the Policy Engine will apply the first ACE that matches the request?s subject and resource. It is up to the policy author to ensure that the intended policy is reflected in the ACL of the device. Ambiguities such as duplicate ACE for the same subject and resource are beyond the scope of the Policy Engine to resolve, as it is not possible to determine the intended policy in these cases without additional metadata in the ACE entries (e.g. some sort of ?priority? field, etc.). Least Privilege might be one assumption to make, however this is also up for interpretation, as (for example) some resources may consider Read to be a greater privilege than Write. Therefore the provisioning entity must ensure that the intended policy is reflected in the entire ACL db of the server device. Thanks, Nathan PS: As you are looking at the current IoTivity SRM code, it is worth noting that there is a forthcoming revision which cleans up a lot of the functionality to be more readable, especially around the AMS portion of the code. It is scheduled to be merged before end of year. From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org<mailto:[email protected]>] On Behalf Of Ashwini Sharma Sent: Monday, November 23, 2015 11:28 PM To: iotivity-dev; Agrawal, Sachin Subject: [dev] SRM ACL/Policy Engine Hi List, Sachin, Policy Engine seems to work on the principle of Least Privilege. I came across an ambiguous situation in this regard. Lets take the case, where user provisioned ACL to device mentioning the SubjectID and resources to be accessed with particular CRUDN access. And then user wanted to update the ACL provisioned. Say in this second instance he just modified the access to be Read-only. I observed that PE still grants permission to perform Write also. On observing the Persistent storage file (json.db), I see that there are two ACE for same Subject and resource. I think the ACE entries should have been updated in this instead of being appended. Similar observation is there when in 1st instance its Read-Only and then updated to all CRUDN. Still only read is allowed. It seems to be matching the Subject, Resource and granting access against the 1st ACE. regards, Ashwini -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20151127/a7b423fe/attachment.html>
