fix: normalize bundled file permissions to world-readable

[kumare3]

Summary

Fixes a permission-denied failure on tasks that use Environment.include to bundle assets (templates, configs, etc.) when the source files have restrictive perms.

A user reported that their git-tracked files are stored with 0o600 perms; when bundled and extracted in the pod, the non-root runtime user could not read them. They asked: can we chmod a+r before packing? Pod-side chmod is not always available — securityContext can block it — so the fix has to happen at pack time.

The bundler already had a tar_strip_file_attributes filter that normalized uid / gid / mtime / pax_headers so the archive doesn't leak host-machine metadata. It deliberately left mode alone, which was the bug: source-tree mode bits aren't portable runtime perms. Extended the same filter to also normalize mode:

• files → 0o644
• directories → 0o755

The executable bit is intentionally dropped — bundled assets are data, not scripts run directly from the bundle. If we ever hit a real case for executable bundled files, we can selectively preserve +x. No flag for opt-out: every other bundle-attribute strip is unconditional, and preserving 0o600 is the actual bug, not a feature.

Changes

• src/flyte/_code_bundle/_utils.py — extend tar_strip_file_attributes to set mode to 0o644 (files) / 0o755 (dirs).
• src/flyte/_environment.py — note the normalization on the include docstring.
• tests/flyte/code_bundle/test_code_bundle.py — 4 new tests:
  • 0o600 file → 0o644 in archive
  • 0o700 dir → 0o755 in archive
  • 0o755 script → 0o644 in archive (exec bit dropped)
  • end-to-end via create_bundle (the path used by Environment.include)

Test plan

• uv run pytest tests/flyte/code_bundle/ — 60 passed
• Verify on a remote run: bundle a file with chmod 600, confirm it's readable as a non-root pod user after extraction

🤖 Generated with Claude Code

[kumare3]

We are still waiting, to test it fully, cc @ranjit-parva