update install-worker.sh to chmod under more restrictive uname configurations #1717
Conversation
This file contains 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
when running under a more restrictive umask, the chmod +x wouldn't set the r-x bits for the 'other' group. make the chmod more explicit. for example chmod +x under a more restrictive umask ends up without execute pemissions which is likely not what was intended: [jo.diaz@\ ~]$ umask 0027 [jo.diaz@\ ~]$ touch testfile [jo.diaz@\ ~]$ chmod +x testfile [jo.diaz@\ ~]$ ls -l testfile -rwxr-x--- 1 jo.diaz jo.diaz 0 Mar 8 11:39 testfile where under a more typical umask things look more familiar: [jo.diaz@\ ~]$ umask 0002 [jo.diaz@\ ~]$ touch permissive [jo.diaz@\ ~]$ chmod +x permissive [jo.diaz@\ ~]$ ls -l permissive -rwxrwxr-x 1 jo.diaz jo.diaz 0 Mar 8 11:40 permissive so, when using a base AMI with more restrictive umask, update the chmod +x's to be more explicit about what is intended. without these changes, we have seen things error out during the build 2024-03-08T12:02:27-05:00: ==> amazon-ebs: Provisioning with shell script: /home/jo.diaz/projects/amazon-eks-ami/templates/al2/../shared/provisioners/generate-version-info.sh 2024-03-08T12:02:28-05:00: amazon-ebs: /home/ec2-user/script_2147.sh: line 19: /usr/bin/kubelet: Permission denied 2024-03-08T12:02:28-05:00: ==> amazon-ebs: Provisioning step had errors: Running the cleanup provisioner, if present...
the zip file aws installation script relies on some assumptions about the umask set in the environment that the script runs with. running with a restrictive umask like 0027 results in a setup where the installed aws cli isn't usable by regular users: [ec2-user@ip-172-31-8-141 ~]$ ls -al /bin/aws lrwxrwxrwx. 1 root root 37 Mar 11 22:43 /bin/aws -> /usr/local/aws-cli/v2/current/bin/aws [ec2-user@ip-172-31-8-141 ~]$ ls -al /usr/local/aws-cli/ ls: cannot open directory /usr/local/aws-cli/: Permission denied [ec2-user@ip-172-31-8-141 ~]$ ls -al /usr/local/ | grep aws drwxr-x---. 3 root root 16 Mar 11 22:43 aws-cli so wrap the running of the aws cli installer script with a umask that will leave things with a working aws cli for non-root users. with this change the permissions on the directories/files leave the aws cli in a working state. $ ls -l /usr/local/aws-cli/v2/2.15.29/dist/aws -rwxr-xr-x. 1 root root 6714680 Mar 14 15:35 /usr/local/aws-cli/v2/2.15.29/dist/aws
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Issue #, if available:
N/A
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
when running under a more restrictive umask, the
chmod +xwouldn't set the r-x bits for the 'other' group (or potentially the group permissions too depending on the umask). make the chmod more explicit.for example
chmod +xunder a more restrictive umask ends up without execute pemissions which is likely not what was intended:where under a more typical umask things look more familiar:
so, to accommodate using a base AMI with more a restrictive umask, update the
chmod +x's to be more explicit about what is intended.without these changes, we have seen things error out during the build
Also, update the way the AWS CLI is installed to similarly deal with the restrictive umask. Otherwise we end up with a broken aws CLI, which leaves us with errors during the validate script:
Testing Done
Tried a build with an AMI base image with a restrictive umask, and avoided the errors described above.