-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sanitize DagRun.run_id
and allow flexibility
#32293
Conversation
736bffd
to
bf7d84b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The error should be fixed by #32307 . please reabase @ephraimbuddy |
This commit sanitizes the DagRun.run_id parameter by introducing a configurable option. Users now have the ability to select a specific run_id pattern for their runs, ensuring stricter control over the values used. This update does not impact the default run_id generation performed by the scheduler for scheduled DAG runs or for Dag runs triggered without modifying the run_id parameter in the run configuration page. The configuration flexibility empowers users to align the run_id pattern with their specific requirements.
bf7d84b
to
155cfe3
Compare
This commit sanitizes the DagRun.run_id parameter by introducing a configurable option. Users now have the ability to select a specific run_id pattern for their runs, ensuring stricter control over the values used. This update does not impact the default run_id generation performed by the scheduler for scheduled DAG runs or for Dag runs triggered without modifying the run_id parameter in the run configuration page. The configuration flexibility empowers users to align the run_id pattern with their specific requirements. (cherry picked from commit 05bd90f)
It is unclear to me how DAG RUN ID could exploit illegal file access, given the limited information from CVE-2023-22887. But rather than fixing the root cause, we impose a default regex pattern check How can we guarantee that the string from this pattern won't generate any malicious code? Shouldn't we address the root cause instead? We don't fix the SQL injection by limiting the string from users with regex. We validate the SQL string with prepared statements. Regex itself is not a validation but a restriction. |
While working on sanitizing the run_id(apache#32293), I replaced spaces with + which is not an ideal way to quote a URL. This led to issues when users use spaces in their DAG run_id. This commit fixes the issue by using urllib.parse.quote to properly quote the URL.
While working on sanitizing the run_id(#32293), I replaced spaces with + which is not an ideal way to quote a URL. This led to issues when users use spaces in their DAG run_id. This commit fixes the issue by using urllib.parse.quote to properly quote the URL.
This commit sanitizes the DagRun.run_id parameter by introducing a configurable option. Users now have the ability to select a specific run_id pattern for their runs, ensuring stricter control over the values used. This update does not impact the default run_id generation performed by the scheduler for scheduled DAG runs or for Dag runs triggered without modifying the run_id parameter in the run configuration page. The configuration flexibility empowers users to align the run_id pattern with their specific requirements.