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:[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/20151124/cf090537/attachment.html>
