I can say in practice, at least, if I create a rule that opens TCP 22 and another rule that opens TCP 22 through 80, they both show up on the virtual router's iptables. That shouldn't hurt anything, and is actually a bit less confusing. I think I see what you're saying, the first rule listed will match in iptables and will stop processing. I thought you meant that the ACLs would stop being installed on the router according to whether or not they overlap. This behavior I'm seeing makes sense.
Let me try to duplicate in master, as well. This is with 4.2 On Mon, Nov 11, 2013 at 4:38 PM, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > On 11/11/13 3:34 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: > >>On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk >><alena.prokharc...@citrix.com> wrote: >>> On 11/11/13 2:59 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >>> >>>>Sorry for the back and forth, I'm interfacing with individuals who >>>>consume our CloudStack environment. I'm being told that the issues >>>>actually aren't related to API parameters, but behavior of the API >>>>calls: >>>> >>>>1) As a user, listing network ACLs now shows ALL ACLs, not just the >>>>ones you own. An example test that was shown to me created a new user, >>>>listed ACLs, then created two ACLs and listed again. Previously, the >>>>result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand >>>>new user sees all ACLs. >>> >>> Its a bug if the ACLs belong to some other user in the domain as the >>> regular user can see only his own resources. Can you please elaborate >>>who >>> owns 24 and 26 ACLs, and who makes the call (the type of the user - >>>domain >>> admin, root admin, regular user) >> >>Test creates a domain, creates a new user in the domain, lists ACLs as >>that user. ACLs from other domains and accounts are seen (all ACLs, >>as far as I can tell). > > > Sounds like a security bug to me. Kishan, can you take a look pls? > > >> >>> >>>> >>>>2) Test case used to succeed by failing when duplicate or overlapping >>>>ACLs were created. Now, they're allowed. I have yet to duplicate this >>>>and see if it causes problems for virtual routers. >>> >>> >>> Not a bug. If it was the other way around - duplicated rules were >>>allowed, >>> and now we block it - then it would have been a bug because your DB >>>might >>> already have duplicated records prior to update. >>> With the new way ACLs are implemented, you can set the priority for the >>> rule. Once the rule with the highest priority is hit, the rest of the >>> rules are not being processed. You can read the FS to understand how the >>> feature works. Kishan, can you point Marcus to the spec. >> >>Yes, please. This sounds as though someone may create a rule for >>22-80, and another for 80-443, and only one of the rules will work >>(the one with priority). That would cause confusion as far as >>understanding why a rule isn't working. I'll see if I can dig it up on >>my own as well. >> >>> >>> >>>> >>>>I'll try to confirm/duplicate and create JIRA issues for these if I >>>>don't get a response back from someone explaining/validating the new >>>>behavior. >>>> >>>>On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk >>>><alena.prokharc...@citrix.com> wrote: >>>>> Marcus, if any of the CS API command(s) return the error for >>>>> parameter/parameter combination that used to work before, then it >>>>>means >>>>>APIs >>>>> are incompatible, and it has to be fixed. >>>>> Thank you for looking into it. >>>>> >>>>> -Alena. >>>>> >>>>> From: Marcus Sorensen <shadow...@gmail.com> >>>>> Reply-To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>> Date: Monday, November 11, 2013 1:10 PM >>>>> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>> >>>>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs >>>>> >>>>> Ok, I'll dig deeper into it. Our api's ACL tests are breaking against >>>>>4.2. >>>>> >>>>> On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala >>>>> <kishan.kav...@citrix.com> wrote: >>>>> >>>>> Marcus, >>>>> aclid is optional when creating a networlACL. In 4.1, networkId is >>>>> mandatory for creating ACL. So, when networkId is specified instead of >>>>>aclid >>>>> in 4.2, CS gets the aclList associated with the network and adds acl >>>>>to >>>>>it. >>>>> So, API doesn't break if the aclid is not specified. >>>>> >>>>> -----Original Message----- >>>>> From: Marcus Sorensen [mailto:shadow...@gmail.com] >>>>> Sent: Saturday, 9 November 2013 1:13 AM >>>>> To: dev@cloudstack.apache.org >>>>> Cc: Kishan Kavala >>>>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs >>>>> >>>>> Yes, that would certainly maintain api compatibility if one creates an >>>>>ACL >>>>> without specifying aclid, it creates a new list and applies it to the >>>>>given >>>>> network. >>>>> >>>>> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi >>>>> <animesh.chaturv...@citrix.com> wrote: >>>>>> Actually use this link to the message in that thread >>>>>> http://s.apache.org/QKI >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >>>>>>> Sent: Friday, November 08, 2013 11:24 AM >>>>>>> To: dev@cloudstack.apache.org >>>>>>> Cc: Kishan Kavala >>>>>>> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs >>>>>>> >>>>>>> >>>>>>> I will let Kishan comment but found this thread >>>>>>> http://markmail.org/thread/fxzki6ftqacyrylk >>>>>>> >>>>>>> >>>>>>> > -----Original Message----- >>>>>>> > From: Marcus Sorensen [mailto:shadow...@gmail.com] >>>>>>> > Sent: Friday, November 08, 2013 9:13 AM >>>>>>> > To: dev@cloudstack.apache.org >>>>>>> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs >>>>>>> > >>>>>>> > So I take the silence to simply be a collective "oops". I guess >>>>>>> > this just should serve as a reminder to not break API >>>>>>>compatibility >>>>>>> > without a discussion. Perhaps our tests will surface this better >>>>>>>in >>>>>>> > the future (although I need to look, I wonder if any ACL tests >>>>>>>were >>>>>>> > also simply changed to accomodate the new behavior). >>>>>>> > >>>>>>> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen >>>>>>> > <shadow...@gmail.com> >>>>>>> > wrote: >>>>>>> > > Maybe this has been discussed already, but we seem to have run >>>>>>> > > into an api incompatibility. In 4.1, you could create ad-hoc ACL >>>>>>> > > rules that applied to a network. In 4.2, you have to first >>>>>>>create >>>>>>> > > an 'ACL list', then add those rules to the list, then apply the >>>>>>> > > list to a network. Or so it seems. This means that applications >>>>>>> > > that are coded to the cloudstack API and utilize >>>>>>>createNetworkACL >>>>>>> > > will break, because the flow has changed. >>>>>>> > > >>>>>>> > > Am I correct on this? And if so, shouldn't we have deployed 4.2 >>>>>>> > > as 5.0, since the stated versioning is based on API >>>>>>>compatibility? >>>>> >>>>> >>>> >>> >>> >> > >
