Marcus, Filed https://issues.apache.org/jira/browse/CLOUDSTACK-5145 to fix ACL listing of all users.
> -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Tuesday, 12 November 2013 5:20 AM > To: Alena Prokharchyk > Cc: Kishan Kavala; dev@cloudstack.apache.org > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs > > 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? > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >>
