carvel-dev
Remember input file permissions for when using --output-files.
Describe the problem/challenge you have
When you use --output-files, files are always generated with user permissions of rwx------ and the original user permissions are not used. Further, output files have no group/other permissions at all.
This can cause problems due to execute bits being added to files.
Describe the solution you'd like
Remember the user permissions for input files, and when written to disk as separate files when --output-files is used, keep the same user permissions.
It is arguable that the group/other permissions should also be remembered and used as well. Alternatively, at least copy user permissions to group/other, with what permissions persist for those being dependent on users umask.
At the same time directories should always be created with 0777 and allow the active umask to then modify this to remove group/other write bit for example.
Anything else you would like to add:
Nope.
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
(triaged w/ @cari-lynn and @vmunishwar)
This issue was also discussed in #302 and vmware-tanzu/carvel-imgpkg#93.
What's different here is that in this situation, there are a variety of file permissions, all of which are intentionally set and likely having an affect on whether downstream use is successful or not.
For those who are using ytt in the context described in this issue, this behavior is surprising. 👍🏻
As noted in those referenced issues, ytt resets permissions as part of a secure-by-default stance. We expect ytt to be used heavily in automation (containers running in CI or a cluster) which pulls on files sourced from a source code repository wherein the permissions are not necessarily set with information hiding in mind. Such circumstances are (currently) the primary conditions under which ytt is used.
To enable this sort of use-case, we propose adding a flag to the tool specifically to preserve permissions (e.g. --output-files-preserve-permissions).
At this time, the maintainers cannot commit to a timeline for said feature. However, we would make space to support a contribution.
Is --output-files-preserve-permissions intended to be applied on imgpkg push. So the OCI image would contain the full permissions, vs, the idea I proposed of at least unpacking permissions akin to what git does.
The proposed flag is for ytt. We mentioned the corresponding imgpkg GitHub issue for context rather than definition.
Was thinking that we'd preserve the owner's permission bits very much like how imgpkg is — as of v0.7.0 — is doing.
Would this be sufficient for this use-case, @GrahamDumpleton?
Ahhh, getting things mixed up my head again. :-)
As to what you are suggesting, seems I still need to fix up group/other permissions since it is the loss of them which is also part of the issue for me.
seems I still need to fix up group/other permissions since it is the loss of them which is also part of the issue for me.
Can you elaborate on the difficulty, there? What happens/breaks when you lose the "group" and/or "other" permissions?
As separately explained with imgpkg there are situations like where using the output as subsequent input to a docker build that can result in failure when group/other permissions are lost. Eg., files copied into a docker image which when run as a container is run as non root, which then fails as non root user can't read the files copied into the image as group/other permissions were thrown away by ytt when generating files with --output-files. Adding execute bits on everything causes problems in things such as setup.d like handling where scripts are executed only if the script is executable. By adding execute bits to everything, that means scripts could be run which weren't intended to be run.
Well, then. I'm apt to want to preserve all permissions: all nine bits for existing files, umask for new files.