restrict permissions on teradata credential files written for ssh runs - #71766
Open
Samin061 wants to merge 1 commit into
Open
restrict permissions on teradata credential files written for ssh runs#71766Samin061 wants to merge 1 commit into
Samin061 wants to merge 1 commit into
Conversation
The remote (SSH) execution paths wrote the tbuild script, tdload job-variable file, and BTEQ script (all embedding the connection password) at the process umask, while the local-execution siblings already narrow the same files to owner-only. Apply the same restriction so credentials are not left group- or world-readable before encryption and transfer.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Teradata remote-execution paths write the tbuild script, the tdload job-variable file, and the BTEQ script to a local temp file before encrypting and transferring them, and each of those embeds the connection password (
UserPassword/TargetUserPasswordfor TPT,.LOGON <host>/<user>,<password>for BTEQ). The local-execution siblings already restrict those files to the owner throughset_local_file_permissions, but the three SSH paths left them at the process umask, so under a common umask the credential files are group- and world-readable on disk before transfer. This applies the same owner-only restriction at the three remote-execution sites and adds regression tests.Was generative AI tooling used to co-author this PR?