[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913250#comment-17913250
]
Hadoop QA commented on OOZIE-3719:
--
Testing JIRA OOZIE-3719
Cleaning local git workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any star imports
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:green}+1{color} the patch adds/modifies 4 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} Javadoc generation succeeded with the patch
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warning(s)
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:orange}0{color} There are [28] new bugs found in total that would be
nice to have fixed.
.{color:orange}0{color} There are [13] new bugs found in [core] that would
be nice to have fixed.
.You can find the SpotBugs diff here: core/findbugs-new.html
.{color:green}+1{color} There are no new bugs found in [examples].
.{color:green}+1{color} There are no new bugs found in [sharelib/streaming].
.{color:green}+1{color} There are no new bugs found in [sharelib/hive2].
.{color:green}+1{color} There are no new bugs found in [sharelib/hive].
.{color:green}+1{color} There are no new bugs found in [sharelib/git].
.{color:green}+1{color} There are no new bugs found in [sharelib/spark].
.{color:green}+1{color} There are no new bugs found in [sharelib/distcp].
.{color:green}+1{color} There are no new bugs found in [sharelib/sqoop].
.{color:green}+1{color} There are no new bugs found in [sharelib/pig].
.{color:green}+1{color} There are no new bugs found in [sharelib/hcatalog].
.{color:green}+1{color} There are no new bugs found in [sharelib/oozie].
.{color:orange}0{color} There are [15] new bugs found in [tools] that would
be nice to have fixed.
.You can find the SpotBugs diff here: tools/findbugs-new.html
.{color:green}+1{color} There are no new bugs found in [client].
.{color:green}+1{color} There are no new bugs found in [server].
.{color:green}+1{color} There are no new bugs found in [docs].
.{color:green}+1{color} There are no new bugs found in
[fluent-job/fluent-job-api].
.{color:green}+1{color} There are no new bugs found in [webapp].
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.Tests run: 2392
.Tests failed : 3
.Tests in error : 14
.Tests timed out : 1
{color:red}-1{color} [ERROR] There are [3] test failures in [sharelib]. Listing
only the first [5] ones
testHive2Action:org.apache.oozie.action.hadoop.TestHive2ActionExecutor
{color:red}-1{color} [ERROR] There are [14] test errors in [sharelib]. Listing
only the first [5] ones
Check console output for the full list of errors/failures
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:green}+1 MODERNIZER{color}
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://ci-hadoop.apache.org/job/PreCommit-OOZIE-Build/242/
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch, OOZIE-3719-006.patch,
> OOZIE-3719-007.patch, image-2023-09-15-02-47-52-819.png,
> image-2023-09-15-02-49-14-531.png, image-2023-09-15-02-52-09-320.png,
> oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
>
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913192#comment-17913192
]
Hadoop QA commented on OOZIE-3719:
--
PreCommit-OOZIE-Build started
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch, OOZIE-3719-006.patch,
> OOZIE-3719-007.patch, image-2023-09-15-02-47-52-819.png,
> image-2023-09-15-02-49-14-531.png, image-2023-09-15-02-52-09-320.png,
> oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870681#comment-17870681
]
Dénes Bodó commented on OOZIE-3719:
---
I was not able to fix the build issues in Jenkins nor I will have the bandwidth
to work on it in the near future. Asked help in
[priv...@oozie.apache.org|mailto:private@oozie.apache] ; no response so far.
Best effort I will try to find someone who can do the proper testing or fix
build issues.
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch, OOZIE-3719-006.patch,
> OOZIE-3719-007.patch, image-2023-09-15-02-47-52-819.png,
> image-2023-09-15-02-49-14-531.png, image-2023-09-15-02-52-09-320.png,
> oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866680#comment-17866680
]
János Makai commented on OOZIE-3719:
The latest patch looks good to me, thanks [~dionusos]!
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch, OOZIE-3719-006.patch,
> OOZIE-3719-007.patch, image-2023-09-15-02-47-52-819.png,
> image-2023-09-15-02-49-14-531.png, image-2023-09-15-02-52-09-320.png,
> oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866382#comment-17866382
]
Hadoop QA commented on OOZIE-3719:
--
PreCommit-OOZIE-Build started
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch, OOZIE-3719-006.patch,
> OOZIE-3719-007.patch, image-2023-09-15-02-47-52-819.png,
> image-2023-09-15-02-49-14-531.png, image-2023-09-15-02-52-09-320.png,
> oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866243#comment-17866243
]
Hadoop QA commented on OOZIE-3719:
--
PreCommit-OOZIE-Build started
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch, OOZIE-3719-006.patch,
> image-2023-09-15-02-47-52-819.png, image-2023-09-15-02-49-14-531.png,
> image-2023-09-15-02-52-09-320.png, oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866174#comment-17866174
]
Hadoop QA commented on OOZIE-3719:
--
Testing JIRA OOZIE-3719
Cleaning local git workspace
{color:red}-1{color} Patch failed to apply to head of branch
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch,
> image-2023-09-15-02-47-52-819.png, image-2023-09-15-02-49-14-531.png,
> image-2023-09-15-02-52-09-320.png, oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OOZIE-3719) Improve coordinator scope range checking
[
https://issues.apache.org/jira/browse/OOZIE-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866172#comment-17866172
]
Hadoop QA commented on OOZIE-3719:
--
PreCommit-OOZIE-Build started
> Improve coordinator scope range checking
>
>
> Key: OOZIE-3719
> URL: https://issues.apache.org/jira/browse/OOZIE-3719
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.1
>Reporter: Sanjay Kumar Sahu
>Assignee: Sanjay Kumar Sahu
>Priority: Major
> Attachments: OOZIE-3719-001.patch, OOZIE-3719-002.patch,
> OOZIE-3719-003.patch, OOZIE-3719-005.patch,
> image-2023-09-15-02-47-52-819.png, image-2023-09-15-02-49-14-531.png,
> image-2023-09-15-02-52-09-320.png, oozie3719.patch
>
>
> !image-2023-09-15-02-47-52-819.png!
>
> Looking further into the code focusing on the action and type query strings.
> We can see that the filter variable is getting its value from the
> requestsParameters .
> once the Filter parameter is being populated, an If loop checking whether
> Scope and Type are not Null and next
> the code checks the logRetrievalType is equal to the JOB_LOG_ACTION (which is
> the action query string).
>
> Next the values of logRetrievalScope gets split by , and entering the the if
> loop.
> In the block where ranges of actions are processed ( if (s.contains("-")) \{
> ... } ), an attacker could potentially
> send a specially crafted request with a massive range, such as "1-100".
> This would create a for loop
> iterating and adding that many actions to the actionSet , consuming CPU and
> memory resources.
> Though there is a subsequent check against maxNumActionsForLog , this check
> only happens after all the iterations,
> allowing an attacker to consume resources before this check is made -
>
> !image-2023-09-15-02-52-09-320.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
