-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AWS] aws_opsworks_permission: cannot set permissions for own user #458
Labels
bug
Addresses a defect in current functionality.
Comments
charles-at-geospock
added a commit
to charles-at-geospock/terraform-provider-aws
that referenced
this issue
Jul 2, 2017
When the permissions being changed in OpsWorks were only the flags for the sudo and ssh permissions of the current user, terraform would send a 'level' parameter containing an empty string. This is not valid, and AWS will respond to the request saying you cannot change your own privilege level. Clearly an empty string ("") is not taken as being 'unchanged', but nil is. This change detects that an empty string would be sent to AWS and if so, sends 'nil' in its place (which makes the parameter unset, and allows the operation). Consequently, this allows the OpsWorks SetPermissions operation to complete, changing the Sudo or SSH permissions. Fixes: hashicorp#458
radeksimko
pushed a commit
that referenced
this issue
Jul 3, 2017
* Fix OpsWorks 'set permissions' failing to set ssh access. When the permissions being changed in OpsWorks were only the flags for the sudo and ssh permissions of the current user, terraform would send a 'level' parameter containing an empty string. This is not valid, and AWS will respond to the request saying you cannot change your own privilege level. Clearly an empty string ("") is not taken as being 'unchanged', but nil is. This change detects that an empty string would be sent to AWS and if so, sends 'nil' in its place (which makes the parameter unset, and allows the operation). Consequently, this allows the OpsWorks SetPermissions operation to complete, changing the Sudo or SSH permissions. Fixes: #458 * Update ChangeLog reference to ssh permissions ticket. The ticket is commonly referenced in the CHANGELOG.md file, but this had not been done. * Change assignment to be more idiomatic. The 'GetOk' method makes the assignment of these optional variables a lot easier. * Omit Changelog changes
ghost
mentioned this issue
Jun 11, 2018
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked and limited conversation to collaborators
Apr 11, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This issue was originally opened by @NicolasFrd as hashicorp/terraform#11001. It was migrated here as part of the provider split. The original body of the issue is below.
Terraform Version
Terraform v0.8.2
Affected Resource
aws_opsworks_permission
Terraform Configuration Files
Expected Behavior
Changing the instance access permissions "allow ssh" and "allow sudo" of my own user in the Opsworks stack permisions
Actual Behavior
AWS responded with status code 400, stating:
ValidationException: Unable to change own permission level. Only AllowSsh and AllowSudo allowed.
It appears that Terraform is setting the
level
in the AWSSetPermission
request, althoughlevel
was omitted in the Terraform resource (which is ok since it is optional).This is then rejected by AWS, as a user is not allowed to set his own permission level.
Steps to Reproduce
terraform plan
terraform apply
References
There was a fix concerning the
level
in this resource: hashicorp/terraform#9104We believe this introduced the problem, since we didn't encounter it with previous versions of Terraform. We also noticed that there was no acceptance test for this resource that does not set the
level
.Thanks a lot! I'm looking forward to hearing from you.
The text was updated successfully, but these errors were encountered: