potiuk opened a new issue, #71080:
URL: https://github.com/apache/airflow/issues/71080
`requires_access_backfill` resolves the Dag for the authorization decision
from the `backfill_id` path parameter. When that id is present and parses, but
no `Backfill` row matches, `dag_id` stays `None` and the dependency falls
through to reading `dag_id` from the request body — so the decision is made
against a Dag the *request names* rather than the backfill in the path.
This is not exploitable for a cross-Dag action: the handler answers 404
before acting, so nothing is done to another Dag's backfill. What it does leak
is existence. A caller can tell "no such backfill" (404) apart from "backfill
exists on a Dag you cannot see" (403), which is an existence oracle over
backfill ids across Dags.
### Why the fallback is there
`requires_access_backfill` is not only on `/{backfill_id}` routes — it also
guards `GET /backfills`, `POST /backfills` and `POST /backfills/dry_run`, where
there is no `backfill_id` at all and the Dag legitimately comes from the body.
Any fix has to keep those working.
### Suggested shape
Distinguish "no `backfill_id` in the path" from "`backfill_id` given but not
found". The body fallback should apply only to the first. In the second the
dependency should decide without consulting the body, and the response for an
unknown backfill should be indistinguishable from the unauthorized one.
### Acceptance criteria
- A request with a well-formed but unknown `backfill_id` never has its
authorization decided by a body-supplied `dag_id`.
- An unauthorized caller cannot distinguish an unknown backfill id from one
on a Dag they cannot access.
- The three body-based routes above keep authorizing off the body.
Raised in review of #70889, which deliberately scoped itself to the parser
divergence: https://github.com/apache/airflow/pull/70889#discussion_r3710514595
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
