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> 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] *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/20151126/cdccf5fb/attachment.html>
