search

actions / upload-artifact

MIT License
3.26k stars 739 forks source link

@v4 breaks workflows when using unprivileged containers #542

Closed pburkholder closed 8 months ago

pburkholder commented 8 months ago

What happened?

The following job using OpenSSF AllStar fails with upload-artifact@v4:

jobs:
  deployment:
    runs-on: ubuntu-latest
    # Use chainguard/busybox based image - It has a tail.
    container: ghcr.io/ossf/allstar:v4.0-busybox
    environment: prod
    steps:
    - run: mkdir -p /tmp/artifact
    - run: echo hello > /tmp/artifact/world.txt
    - uses: actions/upload-artifact@v4
      with:
        name: my-artifact
        path: /tmp/artifact/world.txt

The error is:

Artifact my-artifact.zip successfully finalized. Artifact ID 1315437967
Artifact my-artifact has been successfully uploaded! Final size is 140 bytes. Artifact ID is 1315437967
Error: EACCES: permission denied, open '/__w/_temp/_runner_file_commands/set_output_5aff326e-29e9-40af-b476-10b4515e53fa'

What did you expect to happen?

I expect the workflow not to fail.

How can we reproduce it?

See https://github.com/pburkholder/.allstar/blob/main/.github/workflows/blank.yml for the working worflow. Change @v3 to @v4 to reproduce.

Anything else we need to know?

Downgrading to @v3 does not have the FAIL errors that break the workflow.

I'm not sure exactly which version I'm using. How can I can check?

What version of the action are you using?

4.3.1 (5d5d22a31266ced268874388b861e4b58bb5c2f3)

What are your runner environments?

linux

Are you on GitHub Enterprise Server? If so, what version?

no

pburkholder commented 8 months ago

V3 uses Node 16, which is deprecated so that's not really a reasonable workaround.

pburkholder commented 8 months ago

Based on the lack of activity at https://github.com/actions/checkout/issues/956 (opened Oct 2022) and https://github.com/actions/cache/issues/957 (opened Oct 2022) seems GitHub has no interest in addressing this with default actions that run in unprivileged containers.

pburkholder commented 8 months ago

I'm closing this because running --root does not seem to contravene federal requirements as I first thought.

In re-reading the actual STIG, I think the restrictions regard the container's privileges on the container platform, not internal to the running container, and using root as the user internal to the container is A-OK.