Apply configured bundle permissions to cloned repos for impersonation

[Dev-iL]

- This PR was created with the help of AI

Depends on: #60270

Specific issues addressed:

1. Repository file permissions: Cloned repositories inherit default umask permissions, which may not allow group access for impersonated users
2. Git "dubious ownership" error: Git 2.35.2+ refuses to operate on repositories owned by different users without explicit safe.directory configuration

Changes

1. _apply_permissions_recursively(path)
   New helper function that walks a directory tree and applies the configured dag_bundle_new_folder_permissions and dag_bundle_new_file_permissions to all directories and files.

2. _configure_git_safe_directory(path)
   New helper function that adds the repository path to git's global safe.directory configuration, allowing git operations by users who don't own the repository.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[ephraimbuddy]

You should have included the other PR and mark this as dependent on that one

[Dev-iL]

I figured it would be easier to review in isolation.

Is there any specific way to mark a dependency? I did note it at the top of the PR description.

[Dev-iL]

I rewrote the changes to be standalone via common.compat.

[ephraimbuddy]

What if the run_as_user is configured in only one task?

[Dev-iL]

This is perhaps slightly more permissive than strictly necessary. However, even if only one task uses run_as_user, the repository still needs to be accessible during DAG parsing, and having consistent permissions simplifies the security model.

How about I add the following docstring explaining this design decision?

def _apply_permissions_recursively(path: Path) -> None:
    """
    Apply configured bundle permissions to a directory tree.
    
    This ensures that when user impersonation is used, the impersonated user
    can access the cloned repository files.  Permissions are applied at clone
    time regardless of whether all or only some tasks use run_as_user, because: 
    1. DAG parsing needs access before task execution
    2. Bundles may serve multiple DAGs with different impersonation settings
    3. Applying permissions upfront provides a consistent security model
    
    :param path: The root path to apply permissions to recursively
    """

[uranusjr]

I’m not sure if this is a good idea… I’d not expect my global Git config to be silently changed. Can this be repo-local instead?

[uranusjr]

Also, why does this need to use a subprocess instead of the GitPython API?

[Dev-iL]

• Why global: I believe repository-local config is ignored for security reasons (otherwise malicious repos could whitelist themselves). Airflow typically runs in controlled environments (containers/VMs), modifying the global git config for the airflow user should be acceptable.
• Why not GitPython:
  1. We need to configure safe.directory before creating the Repo object (L234), because GitPython internally runs git commands during Repo initialization. If the ownership check fails at that point, we get an exception before we can configure anything.
  2. While GitPython has GitConfigParser that can write to any config file, using it for ~/.gitconfig would essentially reimplement git config --global with more code.

[Dev-iL]

Another approach to consider:

If cloning a bare repository or a repository intended for multiple users (using git clone --shared), Git can be told to ignore the umask and use a specific scheme via the core.sharedRepository setting:

• group (or true): Makes the repository group-writable (ignores umask for the group bits).
• all (or world): Makes the repository readable by everyone.
• 0xxx: An explicit octal mode (e.g., 0660).

[Dev-iL]

Closing because a broader solution is preferred. See also: #60270 (comment)