I mean that it's like SQL injection. API call expects UUID for resourceID,
but in code that API value is checked against resourceID which is integer
and internal to DB and against resourceUuid which is known for API... This
looks weird even without keeping in mind it grabs extra irrelevant results
during the search.

22 нояб. 2017 г. 6:05 ПП пользователь "Ivan Kudryavtsev" <
kudryavtsev...@bw-sw.com> написал:

> Hi, Rafael, 'IN" because API call assumes that several resourceIds can be
> provided, so IN solves it, EQ doesn't.
>
> But despite semantics ID/UUID you see that ID is integer and UUID is
> string and that comparison does fault positive results, next when object
> access for caller is checked exception occured and no tag removal happen as
> a result because int(2) eq '2afcffdsfdsfds-... (UUID)".
>
> 2017-11-22 18:01 GMT+07:00 Rafael Weingärtner <rafaelweingart...@gmail.com
> >:
>
>> Are ID and UUID set with the same values in that entity? If not, the
>> criteria seem correct. I mean, it is trying to filter for an ID if it
>> exists or by UUID if it exists in the entity that is passed as an example.
>> What I do not understand is that they are using “SearchCriteria.Op.IN”,
>> but
>> in my opinion, it should be “SearchCriteria.Op.EQ”.
>>
>> On Wed, Nov 22, 2017 at 7:58 AM, Ivan Kudryavtsev <
>> kudryavtsev...@bw-sw.com>
>> wrote:
>>
>> > Hi, I found interesting behaviour with tags:
>> >
>> > mysql> SELECT resource_tags.id, resource_tags.uuid, resource_tags.key,
>> > resource_tags.value, resource_tags.domain_id, resource_tags.account_id,
>> > resource_tags.resource_id, resource_tags.resource_uuid,
>> > resource_tags.resource_type, resource_tags.customer FROM resource_tags
>> > WHERE  ( resource_tags.resource_id='2a4264fb-9f63-4d4f-9465-c1bc5440e
>> a60'
>> > OR
>> > resource_tags.resource_uuid=_binary'2a4264fb-9f63-4d4f-9465-
>> c1bc5440ea60'
>> > )
>> >  AND resource_tags.resource_type = 'Account';
>> >
>> > +----+--------------------------------------+-------+-------
>> > +-----------+------------+-------------+--------------------
>> > ------------------+---------------+----------+
>> > | id | uuid                                 | key   | value | domain_id
>> |
>> > account_id | resource_id | resource_uuid                        |
>> > resource_type | customer |
>> > +----+--------------------------------------+-------+-------
>> > +-----------+------------+-------------+--------------------
>> > ------------------+---------------+----------+
>> > |  7 | 95a1a314-2247-4622-a33f-b9b2680bc2e1 | test  | me    |
>>  1 |
>> >        2 |           2 | 3199fc71-cf39-11e7-af5d-dc0ea16ecd7f | Account
>> >   | NULL     |
>> > | 10 | 6c247aa1-5524-4910-9b5f-c6cfd9b3bdd9 | test3 | me    |
>>  1 |
>> >        4 |           4 | 2a4264fb-9f63-4d4f-9465-c1bc5440ea60 | Account
>> >   | NULL     |
>> > | 12 | 25fb7848-af34-42f7-855e-0f5909a4e979 | test5 | me2   |
>>  1 |
>> >        4 |           4 | 2a4264fb-9f63-4d4f-9465-c1bc5440ea60 | Account
>> >   | NULL     |
>> > +----+--------------------------------------+-------+-------
>> > +-----------+------------+-------------+--------------------
>> > ------------------+---------------+----------+
>> > 3 rows in set, 1 warning (0.01 sec)
>> >
>> > Don't see that "resource_type" is "account". I just play with it.
>> >
>> > Take a look at ID=7. This row is found because:
>> >
>> > resource_tags.resource_id='2a4264fb-9f63-4d4f-9465-c1bc5440ea60' when
>> > right
>> > part is converted to int. Corresponding code is here:
>> >
>> > https://github.com/apache/cloudstack/blob/87ef8137534fa79810
>> 1f65c6691fcf
>> > 71513ac978/server/src/com/cloud/tags/TaggedResourceManagerIm
>> pl.java#L301
>> >
>> > sb.and().op("resourceId", sb.entity().getResourceId(),
>> > SearchCriteria.Op.IN);
>> > sb.or("resourceUuid", sb.entity().getResourceUuid(),
>> SearchCriteria.Op.IN
>> > );
>> > sb.cp();
>> > sb.and("resourceType", sb.entity().getResourceType(),
>> > SearchCriteria.Op.EQ);
>> >
>> > I don't know why the writer uses "resourceId" or "resourceUuid". I
>> suppose
>> > it's a bug and code should be transformed to:
>> >
>> > sb.and("resourceUuid", sb.entity().getResourceUuid(),
>> SearchCriteria.Op.IN
>> > );
>> > sb.and("resourceType", sb.entity().getResourceType(),
>> > SearchCriteria.Op.EQ);
>> >
>> > Or MySQL query should be transformed to:
>> >
>> > mysql> SELECT resource_tags.id, resource_tags.uuid, resource_tags.key,
>> > resource_tags.value, resource_tags.domain_id, resource_tags.account_id,
>> > resource_tags.resource_id, resource_tags.resource_uuid,
>> > resource_tags.resource_type, resource_tags.customer FROM resource_tags
>> > WHERE  ( concat("%", resource_tags.resource_id) =
>> > '2a4264fb-9f63-4d4f-9465-c1bc5440ea60' OR
>> > resource_tags.resource_uuid=_binary'2a4264fb-9f63-4d4f-9465-
>> c1bc5440ea60'
>> > )
>> >  AND resource_tags.resource_type = 'Account';
>> > +----+--------------------------------------+-------+-------
>> > +-----------+------------+-------------+--------------------
>> > ------------------+---------------+----------+
>> > | id | uuid                                 | key   | value | domain_id
>> |
>> > account_id | resource_id | resource_uuid                        |
>> > resource_type | customer |
>> > +----+--------------------------------------+-------+-------
>> > +-----------+------------+-------------+--------------------
>> > ------------------+---------------+----------+
>> > | 10 | 6c247aa1-5524-4910-9b5f-c6cfd9b3bdd9 | test3 | me    |
>>  1 |
>> >        4 |           4 | 2a4264fb-9f63-4d4f-9465-c1bc5440ea60 | Account
>> >   | NULL     |
>> > | 12 | 25fb7848-af34-42f7-855e-0f5909a4e979 | test5 | me2   |
>>  1 |
>> >        4 |           4 | 2a4264fb-9f63-4d4f-9465-c1bc5440ea60 | Account
>> >   | NULL     |
>> > +----+--------------------------------------+-------+-------
>> > +-----------+------------+-------------+--------------------
>> > ------------------+---------------+----------+
>> > 2 rows in set (0.00 sec)
>> >
>> > Let me your thoughts and I'll fix it. Right now, obviously it's a bug.
>> >
>> >
>> >
>> > --
>> > With best regards, Ivan Kudryavtsev
>> > Bitworks Software, Ltd.
>> > Cell: +7-923-414-1515
>> > WWW: http://bitworks.software/ <http://bw-sw.com/>
>> >
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks Software, Ltd.
> Cell: +7-923-414-1515
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
>

Reply via email to