TEP-0127: make stdout and stderror paths readable

[chitrangpatel]

Changes

Prior to this, permission of the stdout and stderr file was 0600. Users would set this path to be the same as result path (see here for example). When using sidecar-logs to extract results, the sidecar would run into read permission error because of this. This PR loosens the permissions of the files generated this way to 0644 so that they can be read by other containers in the pod.

One of the goals of TEP-0011 was to Allow the stdout/stderr of a step to be consumed by another step. Permissions of 0600 does not seem aligned with it.

Note that other files have standard permissions (ie. they are readable by other containers).
Note that the file is still only writable by the user (ie. we are not granting more than read permissions to others 0600 --> 0644).

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

Make stdout and stderr files readable by all.

/kind feature

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
cmd/entrypoint/runner.go	84.4%	82.8%	-1.6

[abayer]

I think this is fine, but I'm always nervous about changing 0600 permissions to 0644 - there's often some scenario I'm not thinking of. So let's page in @tektoncd/core-maintainers =)

[jerop]

also adding @wlynch who implemented it in #5261

[wlynch]

The main risk here is it allows steps to read the stdout/stderr of other steps, which may include secrets, other PII, etc. However, we weren't really preventing this before - IIUC this would work as is if the container user ids happen to match (which AFAIK we don't enforce any policies on).

Based on https://github.com/tektoncd/community/blob/main/teps/0011-redirecting-step-output-streams.md#motivation it looks like being able to read stdout across steps was intentional, but not sure if this opinion has changed (esp. given that based on this PR it hasn't been fully working for awhile now).

If we're okay with containers having full read access to other steps output, this change is fine. Otherwise we'd need to think about a more complex GID / mounting process and grant access that way.

[afrittoli]

@wlynch makes a good point that we don't actively prevent this today.
However we don't make it easier either, and this change would do so.

What makes me slightly nervous here is that it is possible to inject sidecars on pod creation (i.e. like Istio does) and those sidecars would have access to logs as well. That said, if someone has access to injecting sidecars, they probably have access to pod logs too, so maybe it's not an issue after all.

[vdemeester]

@wlynch makes a good point that we don't actively prevent this today. However we don't make it easier either, and this change would do so.

What makes me slightly nervous here is that it is possible to inject sidecars on pod creation (i.e. like Istio does) and those sidecars would have access to logs as well. That said, if someone has access to injecting sidecars, they probably have access to pod logs too, so maybe it's not an issue after all.

I tend to agree with @wlynch and @afrittoli, not really nervous about this.
So 👍🏼 from me.

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bradbeck, dibyom, jerop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dibyom,jerop]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dibyom]

Merging this since we don't seem to have any concerns at the moment
/lgtm

[chitrangpatel]

/retest