Yes, master as of today lists all acls with a newly created user-level account.
On Mon, Nov 11, 2013 at 4:46 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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? >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >>
