On Fri, 2015-08-21 at 13:25 +0200, Aleksander Zdyb wrote:
> Example:
Let me modify the example slightly to cover the case you refer to below
("order of buckets searching"). It doesn't make sense, but let's assume
that we have two additional buckets for access-internet:
> In MAIN bucket, there is this policy:
>
> Client User Privilege Policy
> ------------------------------------------------
> ... ... ... ...
* * access-internet -> INTERNET1
* * access-internet -> INTERNET2
> ... ... ... ...
> ------------------------------------------------
> Default policy: DENY
>
>
In INTERNET1 bucket:
>
> Client User Privilege Policy
> ------------------------------------------------
> ... ... ... ...
> cli-app-1 5000 access-internet ALLOW
> ... ... ... ...
> ------------------------------------------------
> Default policy: DENY
And INTERNET2 bucket:
Client User Privilege Policy
------------------------------------------------
... ... ... ...
cli-app-1 5000 access-internet DENY
... ... ... ...
------------------------------------------------
Default policy: ALLOW
> About order of buckets searching, there is absolutely no rule (except
> the one,
> that Cynara starts from MAIN bucket). And please remember, that the same
> goes
> to rules itself -- Cynara checks all matching rules in arbitrary order
> and picks
> "the least allowing", i.e. preferring DENY to any other.
So in the modified example above, for (cli-app-1, 5000,
access-internet), it will check both buckets and pick "DENY" from the
rule in INTERNET2?
And for (cli-app-2, 5000, access-internet), it will pick "DENY" because
of the default of INTERNET1 (assuming that ... do not contain a matching
rule)?
> Hopefully this explains buckets concept. In case of any further
> question, please
> don't hesitate to ask.
Yes, if I got it right above, then it did. This definitely should be
documented, though, if it is not already.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
