cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: api incompatibility between 4.1 and 4.2 in ACLs
Date Mon, 11 Nov 2013 23:38:16 GMT
On 11/11/13 3:34 PM, "Marcus Sorensen" <shadowsor@gmail.com> wrote:

>On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk
><Alena.Prokharchyk@citrix.com> wrote:
>> On 11/11/13 2:59 PM, "Marcus Sorensen" <shadowsor@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.Prokharchyk@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 <shadowsor@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.Kavala@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:shadowsor@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.chaturvedi@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.chaturvedi@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:shadowsor@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
>>>>>> > <shadowsor@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?
>>>>
>>>>
>>>
>>
>>
>



Mime
View raw message