Skip to content
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

Closed
hashibot opened this issue Jun 13, 2017 · 1 comment · Fixed by #1038
Closed

[AWS] aws_opsworks_permission: cannot set permissions for own user #458

hashibot opened this issue Jun 13, 2017 · 1 comment · Fixed by #1038
Labels
bug Addresses a defect in current functionality.

Comments

@hashibot
Copy link

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

resource aws_opsworks_permission sudo_users {
  allow_ssh = true
  allow_sudo = true
  user_arn = MY_OWN_USER_ARN
  stack_id = MY_STACK_ID
}

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 AWS SetPermission request, although level 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

  1. Use the configuration above to define a resource changing the Stack instance access permissions of your own user
  2. terraform plan
  3. terraform apply

References

There was a fix concerning the level in this resource: hashicorp/terraform#9104

We 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.

@hashibot hashibot added the bug Addresses a defect in current functionality. label Jun 13, 2017
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
Copy link

ghost commented Apr 11, 2020

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 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.
Labels
bug Addresses a defect in current functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant