cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: api incompatibility between 4.1 and 4.2 in ACLs
Date Mon, 11 Nov 2013 23:49:49 GMT
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 <shadowsor@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.Prokharchyk@citrix.com> wrote:
>> 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